Subject: RE: initiating a discussion on mpls singaling protocols

From: "George Young" <[email-masked]>
Date: Thu, 18 Jul 2002 10:08:37 -0400

As one of the GMPLS Survey respondents in the RSVP-TE camp, I support this proposal.

Regards,
George R. Young
Meriton Networks Inc.
3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9628
email: [email-masked]

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, July 18, 2002 7:42 AM
> To: MPLS wg
> Cc: George Swallow; scott Giles; Wijnen, Bert (Bert)
> Subject: initiating a discussion on mpls singaling (sic) protocols
> 
> 
<snip>
> 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.
> 
> <snip>

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 18 Jul 2002 10:19:03 -0400

> implementations.

At this point, a deployment survey would be even more indicative.

Dimitry

---

From: John Drake <[email-masked]>
Date: Thu, 18 Jul 2002 07:58:56 -0700

'Yes' is a good answer to the question

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 4:42 AM
To: MPLS wg
Cc: George Swallow; scott Giles; Wijnen, Bert (Bert)
Subject: initiating a discussion on mpls singaling protocols

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.

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: "Cheenu Srinivasan" <[email-masked]>
Date: Thu, 18 Jul 2002 11:59:18 -0400

I am in favor of this proposal.

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 19 Jul 2002 12:21:46 +0530

Yes, your first couple of paras talk about number of LSPs and failure
recovery. But even, for this refresh reduction has to be turned on. Its an
additional add on , in terms of complexity,state info and code.This is only
one aspect of the scaling. The other is as you said large number of LSPs
going on and off. Scalability is not just a question of just whether you can
manage, but also if its efficient to do it the way its done.

Vijay

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Friday, July 19, 2002 12:12 PM
To: Vijayanand C - CTD, Chennai.
Subject: Re: initiating a discussion on mpls singaling protocols

Did you actually read the first two paragraphs of my comment? RSVP-TE 
does scale. Period.

- Ping

Vijayanand C - CTD, Chennai. wrote:

>>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.
>>
> 
> This is precisely the kind of scalability/performance issue that I ( and
> probably nagabhushana) were pointing to. Soft state is not scalable
always.
> This problem is likely to be acute when  GMPLS networks are fully
deployed. 
> Vijay

---

From: "Balthazar S" <[email-masked]>
Date: Fri, 19 Jul 2002 12:04:33 +0530

I agree with what Vijay and bhushana have to say. IMHO, judging a protocol as redundant just because most of the current implementations (and of course, leading vendors) support RSVP-TE, is not right. As Vijay says, we need to compare the merits-demerits of each protocol before we arrive at a collective decision.
Regards,
Balthazar.

"Vijayanand C - CTD, Chennai." wrote:

I agree with what Bhushana says.We need to look at it from the technical
merits apart from who supports RSVP-TE and who does'nt. 

I think RSVP-TE has become more popular not because of its technical
superiority over CR LDP but purely due to the push it has received from a
few leading vendors, who choose to use it since they already had RSVP. The
support for RSVP-TE is not because of its technical merits but because of
the leading vendors choosing it causing others to meekly follow suit.
However, it is not too late to weigh its merits against CR LDP. 

CR LDP is much more cleaner and has lesser scalability issues. Also, when
one has LDP it is much easier to have CR LDP than extending RSVP for
RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is
advantageous. From an implementors point of view also,having been involved
in implementation of both the protocols, I feel CR LDP is much easier to
understand, implement and maintain. One also needs to look at other
performance issues, which may become critical in GMPLS, I wonder if anyone
has checked it.

Regards,
Vijay

-----Original Message-----
From: Nagabhushana Ramaswamy Nadig
[mailto:[email-masked]]
Sent: Thursday, July 18, 2002 9:45 PM
To: MPLS wg
Subject: Re: initiating a discussion on mpls singaling protocols

This message uses a character set that is not supported by the Internet
Service. To view the original message content, open the attached message.
If the text doesn't display correctly, save the attachment to disk, and then
open it using a viewer that can display the original character set. 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 19 Jul 2002 12:37:08 -0400

Neil,

-> David Charlap wrote 19 July 2002 15:19
-> > Yangguang Xu wrote:
-> > > 
-> > > Cause many folks raise the RSVP-TE soft state issue and its 
-> > apparent drawbacks
-> > > for GMPLS environment. Just a question, if we configure the 
-> > refresh timer very
-> > > large, disable the refresh reduction and also maximize the 
-> > time-out multiplier.
-> > > Will these help, or they make things worse?
-> > 
-> > If you do all of these, then you can no longer detect or 
-> > handle failures 
-> > that don't cause carrier to be lost in the data-plane.
-> NH=> Can you elaborate what you mean by this please David, 
-> and against which
-> particular user-plane framing structure you are referring to 
-> (ie MPLS or SDH
-> or OTN) and whether you are referring to cases where the 
-> signalling is
-> in-band or out-of-band wrt to the traffic's user-plane.  

  What David meant was "You can't make a protocol so *hard*
  by increasing timers and time-out values and achieve
  same dynamics of the *soft-state* protocol".

  There must be some trade-off between soft-state and hard-state.
  If soft-state has scaling problems then make it little hard
  by extensions (that is what RSVP-TE achieved when compared
  to classical RSVP). If you make the protocol too hard then
  how can you make the protocol so dynamic to detect failures
  for better manageability.
 
  I think, Loa confused people by mentioning GMPLS :) (unnecessarily)
  Just consider RSVP-TE applicability as such in core network
  independent of what transport you are using (as a general case).
  Did you see any problem with RSVP-TE in different transport networks
  (when compared to CR-LDP)? I don't think so!

--
Venkata.

---

From: "Black, Stephen" <[email-masked]>
Date: Fri, 19 Jul 2002 11:34:17 -0600

I feel this would be the best approach.

Stephen Black
-----------------------------
Sandia National Laboratories
Networked Sys Surv & Assurance 
email: [email-masked]

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 5:42 AM
To: MPLS wg
Cc: George Swallow; scott Giles; Wijnen, Bert (Bert)
Subject: initiating a discussion on mpls singaling protocols

All,

/Loa

---

From: [email-masked]
Date: Sat, 20 Jul 2002 11:55:04 +0100

Thanks David....I understand where you are coming from, but there are 2
slants on this depending on whether we are discussing pkt-sw networks (MPLS)
or L1 cct-sw networks (GMPLS).  The technical (and for sure the commercial)
requirements are different in each of these cases.  My comments (please see
below) are mainly targeted at the latter.  regards, Neil 

David Charlap wrote 19 July 2002 20:00
> [email-masked] wrote:
> > David Charlap wrote 19 July 2002 15:19
> >>
> >> If you do all of these, then you can no longer detect or 
> >> handle failures that don't cause carrier to be lost in the 
> data-plane.
> > 
> > Can you elaborate what you mean by this please David, and 
> against which
> > particular user-plane framing structure you are referring 
> to (ie MPLS or SDH
> > or OTN) and whether you are referring to cases where the 
> signalling is
> > in-band or out-of-band wrt to the traffic's user-plane.
> 
> Simple.
> 
> Layer-1 protection features will continue to work.  If 
> someone pulls a 
> fiber, carrier will be lost and the interface will go down, and RSVP 
> will handle that.
NH=> Please note in co cct-sw technologies there can be (and in some cases
its forced) disjoint *data-plane networks* carrying the traffic and control
(eg signalling) protocols.....and there could be a even a 3rd disjoint
network carrying the network management protocols.  [This can also be true
for co pkt-sw networks, but of course it is not true in cnls networks.]  In
other words, the fault-management of each of these data-plane networks and
the protocols that run on them is functionally/logically disjoint, and one
should not assume reliance on a signalling (or routing) protocol to proxy
for fault-management of the *traffic's data-plane*.....though of course one
can use these as a tool to detect failures on the data-plane network that is
carrying the signalling/routing say.  However, one should use the failure
indicators from the traffic's data-plane as means to inform the
control-plane (signalling) to trigger actions such as protection-switching
(of the traffic's data-plane) in the case of S-PVC-like trails.  Conversely,
failures of either (i) the data-plane network that carries the control-plane
signalling/routing or (ii) the actual signalling/routing protocol
themselves, should *not* take down the traffic data-plane trails.
> 
> But soft-state also detects software failures.
NH=> Which is fine for detecting failures of either (i) the data-plane
network used to carry the control protocols, or (ii) the control-protocols
themselves......though in the case you are giving here this would only apply
to the signalling protocol component and not the routing protocol component
(that needs, and has, its own fault-management).
> 
> Suppose the RSVP protocol crashes on a box.  The interface 
> remains up.
NH=> Which interface?  The one over which RSVP is running (ie the control
network's data-plane) or the traffic's data-plane?  Recall, I am mainly
talking about L1 co cct-sw networks here and not L2 co pkt-sw
networks....these can have very different requirements.
 
> Packets continue to arrive, but they aren't processed.
> 
> Classical RSVP will detect the loss of refresh messages and 
> will start 
> deleting state as it times out.
NH=> I agree.  RSVP was indeed designed for this environment, and also
Rx-end driven not Tx-end driven applications.  It was not designed to
address the requirements of co cct-sw networks.

> If you increase the refresh 
> interval or 
> multiple, then that amount of time will be much greater.  
> With a default 
> interval of 30 seconds and a default multiple of 3, state 
> will time out 
> in 1.5 minutes.  This is already too slow for many situations.
> 
> The other thing that soft-state gets is reliable delivery.  If a Path 
> message is sent and lost, it will be retransmitted at the 
> next refresh 
> interval, and the LSP should continue coming up at that 
> point.  If the 
> interval is greatly increased, it will take a long time before this 
> retransmission happens.
NH=> Which is great for the original applications for which RSVP was
designed.  If however you start from a perspective of saying 'let's choose a
best-of-breed signalling protocol for co pkt/cct-sw networks' then it seems
hard to believe RSVP would even make the short-list.....pnni/Q.2931 might
however, because it takes precisely this networking model as its basis.  And
the vast majority of the effort here is on exception handling in order to
ensure reliability.  
> 
> The Hello part of RSVP-TE solves the first problem.  When Hellos are 
> used, a failure will be rapidly detected regardless of the 
> refresh interval.
NH=> This does not work if the signalling is running on a disjoint
data-plane network from the traffic's data-plane.  However, more generally
its not good practice to use a control-plane protocol to proxy for the
traffic's data-plane fault-management (and it won't cover all fault types
anyway, eg LSP-Ping attempts to address this issue in the case of pkt-sw
MPLS).
> 
> The Refresh Reduction RFC solves the second problem.  The Message ID 
> part of that RFC will cause trigger messages to be rapidly 
> retransmitted 
> until they are acknowledged (according to an exponential 
> backoff algorithm.)
> 
> Which means it is safe to use a large refresh interval when 
> both Hellos 
> and Refresh Reduction are in use.  But not if they aren't.

regards, Neil

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 20 Jul 2002 17:10:31 +0200

Deployment reports are certainly welcome as input to the process
ove trying to answer this question.
If you want anonymity, I suggest you send them to Loa
privately.

Thanks,
Bert 

> From: Dimitry Haskin [mailto:[email-masked]]
> Sent: donderdag 18 juli 2002 16:19
> To: MPLS wg
> Subject: RE: initiating a discussion on mpls singaling protocols
> 
>

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 22 Jul 2002 15:49:24 +0200

Vijay,
just because you mentioned hundreds of thousands of LSPs, here are my thoughts
why it makes sense to preserve CR-LDP: 

In Yokohame I presented the results of a comparison between four methods as to overcome the O(n**2)-problem
when VPNs shall be built using MPLS tunneling. By far, the best solution is to interconnect the n PEs with n-1 pairs
of mutually inverse-directed elementary LSPs, and then to build merging mp2p H-LSPs as to concatenate some of them
to different sink trees of LSPs.
 
However, these mp2p H-LSPs were to be built in Downstream-Unsolicited mode which requires LDP syntax !

Next, as to identify the (already existing) sub H-LSPs, which are to be concatenated and/or  are to be used
as Control-Plane tunnels, their LSP-IDs are to be known and dealt with. However, LSP-IDs are only provided by CR-LDP,
not by LDP.

And if they should be built using explicit routing, some little extensions to the  
ER-HOP TLV will do.   

It is easier to take the ingrediences from LDP and CR-LDP rather than from LDP and RSVP-TE.

Heinrich

-----Ursprüngliche Nachricht-----
Von: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Gesendet: Montag, 22. Juli 2002 14:39
An: [email-masked]
Cc: [email-masked]
Betreff: Re: initiating a discussion on mpls singaling protocols

In a network where you need to handle hundreds of thousands of LSPs, with a
significant percentage of them going on and off frequently, would the soft
state approach scale effectively ?
By making the behaviour harder by introducing work arounds will we
losing/missing something or killing performance. I think a thorough
performance analysis has to be done on this between CR LDP and RSVP-TE
before coming to a conclusion purely based on numbers in a survey. Numbers
usually come from what the leaders do. 

Implementation ease - I meant, CR LDP is much easier to undestand, implement
and maintain than RSVP-TE( take into account RSVP+LSP_Tunneling + its addons
like Refresh reduction to make it scalable). Also if LDP exists, then CRLDP
is a small add on. Having LDP and CR LDP together and maintaining and
managing it is much easier than LDP+RSVP_TE.

Regards,
Vijay

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Friday, July 19, 2002 7:30 PM
To: Vijayanand C - CTD, Chennai.
Cc: Jean Philippe Vasseur; [email-masked]
Subject: Re: initiating a discussion on mpls singaling protocols

"Vijayanand C - CTD, Chennai." wrote:

> The technical issues are stated in this and subsequent mails and can be
> restated as
> - scalability with efficiency and performance, esp in future GMPLS
networks

Why do you think sclability will be a big issue in the GMPLS networks?
Remeber GMPLS is meant for transport networks. The number of
active connections would be typically less than or equal to the current
number of data connections in a core.

>
> - Ease of implementation and maintenance. A more cleaner protocol than
> RSVP-TE

Ease of implemenatation if you start from the beginning. If you take an
initial
code base from a well-known site and modifying it is not a big deal. Or am I
missing something here?

- sudheer

> - Co-existence with LDP
> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Friday, July 19, 2002 6:03 PM
> Cc: MPLS wg; [email-masked]
> At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote:
> >advantageous.
> don't see the technical arguments there ...
>
> JP.
>
> > From an implementors point of view also,having been involved

---

From: Shahram Davari <[email-masked]>
Date: Mon, 22 Jul 2002 09:14:58 -0700

Hi,

As a neutral observer, I think the choice of a protocol for standardization must be based on technical merits, rather than market share. Imagine standardizing Windows95 as the only standard!

Yours,
-Shahram

---

From: "Stephen Shew" <[email-masked]>
Date: Mon, 22 Jul 2002 15:43:43 -0400

I would like to speak against the proposal to make CR-LDP informational.
Signalling is not the only function in IP in which there are multiple
(standards track) protocols.  Why insist on converging to one?  Also, CR-LDP
is found in other specifications (e.g., OIF UNI 1.0, ITU-T Y.1310) whose
bodies want to continue evolving its functionality.  In particular, the
ITU-T is using GMPLS CR-LDP in its draft recommendation G.7713.3 (CR-LDP
based signalling for ASON).

---

From: Jonathan Lang <[email-masked]>
Date: Mon, 22 Jul 2002 15:53:05 -0700

I agree with the proposal to make cr-ldp informational and progress RSVP-TE
as standards track.

Thanks,
Jonathan

> Sent: Monday, July 22, 2002 5:23 AM
> To: Hummel Heinrich
> Cc: [email-masked]
> Heinrich,
> in my opinion the question is very clearly stated - is there 
> support for
> us (the ietf) to move the cr-ldp from standard track to informational.
> We're "speaking for the ietf", it is more a matter of what we say ;)
> 
> All,
> 
> As usual we are trying to reach a rough consensus. Everyone (i.e. the
> mpls wg) can help create this consensus by answering the question
> above.
> 
> Especially it will be helpful if you were involved in specifying the
> mpls protocols, have implemented or deployed (SP) those protocols, and
> take the time to respond.
> 
> I will be ready to give the first extensive tally mid this week. 
> Currently the count is
> yes: 30 no: 7,
> if you normalize those e.g. by counting each company once it is
> yes: 21 no: 4
> 
> Disclaimer: Given that I've managed to decipher the sometimes cryptic
> mails correctly :o)
> 
> /Loa
> 
> Hummel Heinrich wrote:
> 
> >  I think, the IETF can only speak for itself. There may be 
> other standardization 
> 
> >bodies (ITU-T, MPLS Forum) which may fill 
> > the gap.
> > 
> > Heinrich Hummel
> > Siemens AG
> > 
> 
> 
> -- 
>      Loa Andersson
>      Chief Architect,

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Tue, 23 Jul 2002 10:42:35 +0530

One more point here - A customer/end-user is only going to ask for TE
LSPs/quality of service. I wonder if any end user would name the specific
protocol, or he would care if RSVP-TE or CR LDP is used as long as he gets
the features wants. When two protocols can give the same features, I think
their performance should be the key. Analysis such as those done by Heinrich
would throw more light on the solution.

Vijay

On Mon, 22 Jul 2002, Thomas D. Nadeau wrote:

>
>          Difficulty of  implementation is of little concern at this point
> in the
> game. The point is that customers want to pay for these features so
> vendors that want to sell routers will implement whatever their customers
> tell them to.
>
>          --Tom

Of Course we never have an issue with this, after all money is what can
have a final say in any business. But at the service level what is that,
that
makes RSVP-TE a better option!! That being the case we "have" to look at
the other aspects of ease of implementation (which may be insignificant
today, but I am not sure we may still have some implementations in
future), support for future enhancements, and the whole lot of product
life cycle management issues.

Just my thought....
regards
Bhushana

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

---

From: "Singh, Amritpal (Amritpal)** CTR **" <[email-masked]>
Date: Tue, 23 Jul 2002 03:28:55 -0400

In my view, the best approach is to keep focussing 
on the already pervasive signaling standard that is 
RSVP-TE and let CR-LDP be kept as "informational".

Focus is the keyword here.

So I support this idea.

My 2 cents
Amrit

-----Original Message-----
From: Soumen Sarkar [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 12:57 PM
To: Loa Andersson; [email-masked]
Subject: Re: initiating a discussion on mpls singaling protocols

Loa,
The response so far heavily indicated for RSVP-TE ( obviously not because of
the
merits of RSVP-TE over LDP-CR ). If one has to accept the basic ground-rule,
which is,
how many major players are pushing for RSVP-TE, one would blindly vote for
RSVP-TE.
        The more esoteric view, which is, single signaling protocol would
help
everyone to concentrate better in addressing unresolved  problems in MPLS,
is also
appreciably reasonable to accept.
But looking from holistic perspective, is it not too premature at this time
to
conclude on this issue unilaterally (even if there is 3/4 majority in favour
if it )
when this particular issue affects other standard bodies too ? We know for
sure, OIF
is still tracking LDP-CR as an alternative signaling protocol for optical
control
plane. Are we not pushing something without even considering future
implication of it
? One might say, we are not stopping anyone to use LDP-CR as such. But none
would
disagree that making IETF take a stand itself is deterrant enough and if not
that
much, it is bound to create conflict of interest between IETF and others.
  Are we really ready for this ? IETF traditionally has been more a forum
for vouching
technical solutions, not imposing it. Are we deviating from that path with
full
understanding ?
-best regards,
Soumen

Loa Andersson wrote:

> Heinrich,
>
> in my opinion the question is very clearly stated - is there support for
> >  I think, the IETF can only speak for itself. There may be other
standardization

---

From: "Amritpal Singh" <[email-masked]>
Date: Tue, 23 Jul 2002 09:32:46 +0530

I agree with Loa on this. I think we need to be focussed in our approach.

Making CR-LDP as informational will allow more focus on developing an already pervasive standard to be more refined.

My 2 cents

Amrit

<snip>

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 23 Jul 2002 11:26:56 -0400

Heinrich,

	I don't think this is a fair characterization.

	Several draft authors have participated in work
to develop CR-LDP extensions who have no real interest
in CR-LDP.  This has been done - IMO - out of a sense
of responsible protocol development rather than out of
interest in progressing both signaling protocols.

	Perhaps this is what really needs to change.  If
a specific draft author only wishes to work with one 
signaling protocol, then he or she should be able to
simply do so.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Hummel Heinrich [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 11:13 AM
To: 'avri'
Cc: MPLS wg
Subject: AW: initiating a discussion on mpls singaling protocols

Well spoken.
Additionally, all those who do not care for CR-LDP have hardly contributed
in the past nor will they contribute
in the future to extend routing protocols for the sake of CR-LDP. This sweat
is up to the CR-LDP supporters.
It is not honest to complain about the burden carried by the others.
Heinrich 

-----Ursprüngliche Nachricht-----
Von: avri [mailto:[email-masked]]
Gesendet: Dienstag, 23. Juli 2002 15:26
Cc: MPLS wg
Betreff: Re: initiating a discussion on mpls singaling protocols

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: John Drake <[email-masked]>
Date: Tue, 23 Jul 2002 08:29:43 -0700

I thought that the original comment about Windows was rather odd, since I
didn't think it was up for standardization.

Also, I don't think that any one is proposing to use marketshare as a
metric.  There was some discussion of the GMPLS implementation survey, which
seemed to indicate that not too many people were interested in building
products that had CR-LDP capabilities.

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 8:18 AM
To: Don Fedyk
Cc: Loa Andersson; MPLS wg
Subject: Re: initiating a discussion on mpls singaling protocols

Hi all,

I believe that making a decision on whether RSVP-TE or CR-LDP should be on
standards track based upon marketshare should NOT be how a standards
organization works...  As another person commented, if we're making our
decision based on marketshare then Microsoft Windows would be the standard
for OS, and probably also need to switch to using Word as the default format
for documents...

Zhi

Don Fedyk wrote:

> Hi Loa
>
> I am against the proposal on the belief it is too soon to take this 
> step. If we had applied this policy to the original classical RSVP 
> protocol it would have been information some 5 years ago.
>
> Cheers,
> Don 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 23 Jul 2002 11:43:09 -0400

John,

	This also is not a fair characterization.  :-)

	The survey indicates current implementations.  It
is not possible to infer from such a survey exactly what 
the surveyed vendor's interests are.  Speaking as one
person who has worked with several vendors now in this
area, it seems much more a question of priorities rather
than interests and these priorities are driven by many
factors other than interest.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 8:18 AM
To: Don Fedyk
Cc: Loa Andersson; MPLS wg
Subject: Re: initiating a discussion on mpls singaling protocols

Hi all,

Zhi

---

From: John Drake <[email-masked]>
Date: Tue, 23 Jul 2002 08:51:43 -0700

Eric,

I was using the word 'interest' in the sense  of 'regard for one's advantage
or benefit'.  

Based upon the GMPLS implementation survey, I came to the conclusion that a
number of vendors thought it was to their advantage or benefit to implement
RSVP-TE.

Thanks,

John  

-----Original Message-----
From: Gray, Eric [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 8:43 AM
To: John Drake; 'Zhi-Wei Lin'; Don Fedyk
Cc: Loa Andersson; MPLS wg
Subject: RE: initiating a discussion on mpls singaling protocols

John,

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 8:18 AM
To: Don Fedyk
Cc: Loa Andersson; MPLS wg
Subject: Re: initiating a discussion on mpls singaling protocols

Hi all,

Zhi

---

From: Shahram Davari <[email-masked]>
Date: Tue, 23 Jul 2002 09:00:53 -0700

> number of vendors thought it was to their advantage or 

That advantage or benefit could have been related to the existing RSVP-TE
market share.

-Shahram

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 23 Jul 2002 12:18:48 -0400

George 

September 1997 - July 2002  4.8 years then, I rounded up.
The point was, it is too soon IMHO.

Don 

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
S

> protocol it would have been information some 5 years ago.

Wow! RSVP wasn't even an RFC then.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 23 Jul 2002 12:54:34 -0400

Marty,

	Very acceptable, IMO.

	Many drafts have been deliberately broken up 
to define functional signaling requirements and then
separate drafts were written for signaling.  I would
actually have preferred that the draft authors ONLY
worked on signaling drafts for whichever signaling
approach they were actually implementing.  This does
not seem to have been the case, based on author lists
for the various drafts.  I have not been involved in 
design teams when they were making the decision to 
write signaling specifications for both protocols, so 
I only assume they did so in order to accelerate 
acceptance by the WG.  A secondary goal of ensuring 
consistency I think was more than adequately addressed
by having functional requirements drafts (which are
useful in their own rights).

	I think it is perfectly acceptable to define 
a signaling extension for some application that we
intend to implement using only RSVP-TE.  The problem 
from the start has been the insidious assumption that
anything developed for one _has_ to be developed for
the other.  I think this is what's broken here and
this is what needs to be fixed.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Marty Borden [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 12:38 PM
To: [email-masked]; 'avri'
Cc: [email-masked]
Subject: RE: initiating a discussion on mpls singaling protocols

Eric,
Well that would be good if it were acceptable for a draft
to not have to cover both approaches.  Is that really acceptable?
marty

On 7/23/2002 at 12:09 PM Gray, Eric wrote:

|Avri makes a very good point here.
|
|I think the implementation survey makes it obvious that 
|we should progress RSVP-TE (and related work) to Draft
|Standard.  It seems equally clear that we should not do
|so for CR-LDP at this point.  
|
|Letting CR-LDP die on the vine certainly seems in keeping
|with what the IETF has done in the past.
|
|Eric W. Gray
|Systems Architect
|Celox Networks, Inc.
[email-masked]
|508 305 7214
|
|
|-----Original Message-----
|From: avri [mailto:[email-masked]] 
|Sent: Tuesday, July 23, 2002 9:26 AM
|Cc: MPLS wg
|Subject: Re: initiating a discussion on mpls singaling protocols
|
|
|
|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: Bala Rajagopalan <[email-masked]>
Date: Tue, 23 Jul 2002 13:07:16 -0400

Steve,

Isn't it the case that the only reason that ITU-T (or
OIF for that matter) considers RSVP-TE and CR-LDP because
they're both approved standards from IETF? In other
words, the ITU-T and OIF merely adapt (or adopt)
"existing" protocols for the IP-based control plane.
If IETF decides to stop progressing one of these protocols
further, wouldn't it lighten the (redundant) work
that goes on in the ITU-T? I also don't see why there
ought to be a joint decision between ITU-T and IETF
on this. Given that the ITU-T is at
a stage where the protocol work is still evolving
and no deployment is at stake, it makes good sense to
welcome the move from the IETF to clarify the
signaling protocol picture.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 12:25 PM
> To: Bala Rajagopalan
> Cc: 'Soumen Sarkar'; Loa Andersson; [email-masked]
> Bala,
> There is certainly no issue if both organizations make the same
> decision about which protocol(s) is/are standards track. There is
> only an issue if they make different decisions.
> 
> If a change is to be made in IETF with respect to which protocol(s)
> is/are standards track, it would be worth sending a 
> communication to ITU-T
> with the proposal and reasoning before this is finalized to see if
> an aligned decision could be reached.
> Regards,
> Steve
> 
> Bala Rajagopalan wrote:
> > 
> > In response to the comment on OIF tracking CR-LDP:
> > 
> > Life would be simplified for OIF and ITU-T if
> > there were only a single standard signaling protocol.
> > But because there are two IETF protocols, the rest of the
> > world has to track the two (in addition to other
> > non-IETF protocols).
> > 
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> > 
> > > Sent: Tuesday, July 23, 2002 3:27 AM
> > > The response so far heavily indicated for RSVP-TE ( obviously
> > > not because of the
> > > merits of RSVP-TE over LDP-CR ). If one has to accept the
> > > basic ground-rule, which is,
> > > how many major players are pushing for RSVP-TE, one would
> > > blindly vote for RSVP-TE.
> > >         The more esoteric view, which is, single signaling
> > > protocol would help
> > > everyone to concentrate better in addressing unresolved
> > > problems in MPLS, is also
> > > But looking from holistic perspective, is it not too
> > > premature at this time to
> > > conclude on this issue unilaterally (even if there is 3/4
> > > majority in favour if it )
> > > when this particular issue affects other standard bodies too
> > > ? We know for sure, OIF
> > > is still tracking LDP-CR as an alternative signaling protocol
> > > for optical control
> > > plane. Are we not pushing something without even considering
> > > future implication of it
> > > ? One might say, we are not stopping anyone to use LDP-CR as
> > > such. But none would
> > > disagree that making IETF take a stand itself is deterrant
> > > enough and if not that
> > >   Are we really ready for this ? IETF traditionally has been
> > > more a forum for vouching
> > > technical solutions, not imposing it. Are we deviating from
> > > that path with full
> > > understanding ?
> > > -best regards,
> > > Soumen
> > >
> > > Loa Andersson wrote:
> > >
> > > > Heinrich,
> > > >
> > > > >  I think, the IETF can only speak for itself. There may
> > > be other standardization
> > > >

---

From: [email-masked]
Date: Wed, 24 Jul 2002 11:11:47 +0530

hi soumen!

     I agree with you to a large extent as the basis of evaluation for the two
authorities should (I think is)
     be different and hence irrespective of the fact that whether IETF chooses
RSVP-TE, OIF may
     still go ahead and refine CR-LDP if it feels the need.

     But, I think Bala's point was made with respect to a mail earlier which
referred to OIF using CR-LDP
     primarily for its work right now. Now this discussion here should (going by
your logic and mine above)
     should at all discuss what would be the effect to discontinuing CR-LDP in
IETF on others. As a result of this
     decision someone like OIF/ITU-T may decide their future course of action
but for us (IETF  this decision
     should in no way be influenced by them as of now.

     When at the cross-roads its best not to go hand in hand with someone as
lost as you are, but you might guide
     others once you (carefully) choose the path you want to walk !

cheers,
sumit

Soumen Sarkar <[email-masked]> on 07/24/2002 10:59:24 AM

To:   Bala Rajagopalan <[email-masked]>
cc:   Loa Andersson <[email-masked]>, [email-masked] (bcc: Sumit
      Chauhan/HSS)

So, In effect you are saying that since OIF and ITU-T are not able to decide
which one to pick (based on their requirements), it is benefecial for them
that IETF decide which one they want to promote and others will follow! I
thought ITU-T and OIF work independently and they have their own parameters
to choose the technological alternative.

Bala Rajagopalan wrote:

> > >      R

åsundavägen 12

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 24 Jul 2002 08:53:04 -0400

Lou,

	It should be sufficient to update the MPLS
working group charter.  Suggesting an update to
the CR-LDP Applicability indicates agreement in
words rather than in spirit, since the precedent
set by re-writing an applicability statement to 
indicate that an RFC is not applicable is not 
different - in spirit - than the precedent set 
by simply changing the RFC to an Informational
RFC.

	Nice try, though!  :-)

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 9:29 PM
To: [email-masked]
Cc: Gray, Eric; 'Scott Bradner'
Subject: Re: initiating a discussion on mpls singaling protocols

I like Scott's summary of the issues and choices and 100% agree with
Eric's response.

Assuming that we follow this one step further, and make future
CR-LDP work informational, shouldn't this decision be documented
somewhere?  Maybe in an updated CR-LDP applicability statement?

Is the issue of how to indicate this decision the reason that
reclassification of CR-LDP came up?

Lou

Gray, Eric wrote:
> Scott,
> 
> 	I think it is perfectly acceptable that ongoing work
> on CR-LDP - both current and immediately anticipated - should
> be targeted for Informational RFCs.  The focus needs to be on
> what people who are writing the drafts are implementing and
> it is clear that this is RSVP-TE in nearly every case.  I
> believe most people will agree that this should remove any
> perception that there is a requirement to define everything
> twice in MPLS signaling.  In addition, if the CR-LDP drafts
> are targeted for Informational status, this relieves the WG
> of some of the distraction associated with having to do a
> thorough review of each signaling protocols extension twice.
> 
> 	Please see responses to your specific questions below.
> 
> 	Thanks for putting the issues in a clear perspective!
> 
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [email-masked]
> 508 305 7214
> 
> 
> From: Scott Bradner [mailto:[email-masked]] 
> Sent: Tuesday, July 23, 2002 8:02 PM
> To: [email-masked]
> the question has been asked about reclassifying a already published
> RFC from Proposed Standard to Informational (i.e. de-standardization)
> 
> A/ I do not know of a case where this has been done
> B/ RFC 2026 talks about moving to historic not info
> 
> (in my opinion moving to historc should be done where there is
> a specific strong reason (or reasons) such as security (see RFC 1923
> for an example of stating reasons).)
> 
> my own opinion is that it would set a very precedent to de-standardize at
> all
> and a very bad one to do such a short time after the RFC was published
> 
> I expect we can tell for sure in 4 or 5 years how a technology will be
> received but I doubt that we can tell much in just 6 months
> 
> I think the more important question is about on-going CR-LDP work --
> should be CR-LPD work be relegated to non-standards track?
> 
> specific questions:
> A/ should IETF working group charters be modified to remove a requirement
>    to work on CR-LPD technologies?
> 
> Yes.
> 
> B/ if there is CR-LDP work already in progress, what should happen to it?
> 
> It should be targeted for Informational RFC status.
> Since these drafts are mostly of the form of - if you were going
> to do the same thing using CR-LDP, this is how you would do it -
> therefore, informational status makes more sense.
> 
> C/ if a working group requests publication of RFCs about CR-LDP
>    technology on the standards track what should we do?
> 
> Use the usual procedure of IESG review.  Was the WG chartered to
> do this work?  If so, how did this happen?  I think it is not
> necessary to erect some type of contrived barrier as there will
> be a sufficiently high natural barrier to inappropriate work of
> this kind.
> 
> D/ if someone requests independent publication of RFCs about CR-LPD
>    technology on the standards track (as permitted by RFC 2026) what
>    should we do?
> 
> Again, this would fall under usual procedures.  The RFC Editor
> would typically kick this to the IESG hence causing it to be
> assigned to the appropriate working group (or not) as the IESG
> determines to be appropriate.  As I understand it, the RFC
> Editor is not obliged to publish anything as a standards track
> RFC and will not unless satisfied that the right thing is being
> done by doing so.
> 
> (I see no way for the IETF to refuse to publish CR-LDP related infor or
> experimental RFCs - the IETF is not in the business of suppressing 
> technology)
> 
> Scott
>

---

From: Hummel Heinrich <[email-masked]>
Date: Wed, 24 Jul 2002 12:16:14 +0200

I know. But LDP does. It takes a little bit from LDP, and a little bit from CR-LDP.

But of course, I acknowledge, that both could be taken and combined, even if CR-LDP becomes informational.
Heinrich

-----Ursprüngliche Nachricht-----
Von: David Charlap [mailto:[email-masked]]
Gesendet: Dienstag, 23. Juli 2002 18:46
An: IETF MPLS List
Betreff: Re: AW: initiating a discussion on mpls singaling protocols

Hummel Heinrich wrote:
> 
> But let me repeat my technical point:
> Building hierarchical mp2p LSPs, from the egress towards a set of ingress nodes, i.e.
> building a sink tree out of LSPs. 
> Here downstream unsolicited mode is appropriate. So we need LDP. But because existing LSPs have to be concatenated
> (by label switching) we need their LSP-IDs. And this is provided by CR-LDP.
> 
> It takes a lot more to create RSVP-TE Downstream Unsolicited mode.

I think you are misunderstanding CR-LDP.  It doesn't support downstream 
unsolicited mode either.

-- David

---

From: "Bisewski, Radoslaw" <[email-masked]>
Date: Wed, 24 Jul 2002 12:33:42 +0200

There is at least one additional advantage of the CR-LDP over the RSVP-TE:
CR-LDP is defined as an extensions to the MPLS LDP protocol, while RSVP-TE
has nothing in common with MPLS LDP. It is much easier  to implement MPLS
LDP with CR-LDP extensions than to implement two distinct protocols MPLS LDP
and RSVP-TE.

Regards
Radek 

> Sent: Wednesday, July 24, 2002 12:16 PM
> To: 'David Charlap'; IETF MPLS List
> But of course, I acknowledge, that both could be taken and 
> combined, even if CR-LDP becomes informational.
> Heinrich
> 
> > Here downstream unsolicited mode is appropriate. So we need 
> LDP. But because existing LSPs have to be concatenated

---

From: Shahram Davari <[email-masked]>
Date: Wed, 24 Jul 2002 07:05:44 -0700

Scott,

If future work on CR-LDP is decided to be Informational, will IETF still be concerned with extensions to CR-LDP by other standard organizations?

Yours,
-Shahram

> my own opinion is that it would set a very precedent to 
> de-standardize at all
> C/ if a working group requests publication of RFCs about CR-LPD
> experimental RFCs - the IETF is not in teh business of suppressing 
> technology)
> 
> Scott
>

---

From: tom worster <[email-masked]>
Date: Tue, 23 Jul 2002 20:37:15 -0400

eric wrote:

>   I am not sure that Informational is the right
> way to go.  Perhaps Experimental or Historical is
> better.

i looked through 2026. it makes it clear that the procedure for retiring a
standards track spec is for the iesg to change its status to historic and
that a wg may request the change.

the text in there also says that the informational rfc type is intended for
"timely publication" of pertinent information. it doesn't sound to me like
it was intended as a receptacle for obsolete standards.

but what do i know? if my reading were accurate then the ad would have
pointed this out by now.

c u
fsb

---

From: "David Allan" <[email-masked]>
Date: Wed, 24 Jul 2002 10:23:57 -0400

I also think Avri has raised an important point, and when I saw this item on
the WG agenda, I expected the discussion to be about a move to historical
and not informational status (which I would have considered premature). I
share the expressed concern about de-standardization. 

Seems to me there should be a third path. That is no change to status, and
no longer require or encourage that these protocols be joined at the hip. If
they cross pollinate, so be it, but it is by desire not fiat. Seems to me
that this artificial joining is the actual problem both from a "failure to
differentiate" and "make work" POV.

cheers
Dave

> Sent: Wednesday, July 24, 2002 6:04 AM
> To: Loa Andersson
> Cc: Ong, Lyndon; [email-masked]'; [email-masked]; 'avri';
> [email-masked]
>     Thanks for summarizing. I would support the 2nd approach 
> on the ground that
> Avri has nicely has put forth.
>   2ndly, this approach is very much aligned to IETF's way of working.
> -best regards,
> Soumen
> 
> Loa Andersson wrote:
> 
> > All,
> >
> > (off list for clarification)
> > it seems like you are agreeing based on two very different 
> approaches.
> >
> > 1. don't do anyhting about the doc status to cr-ldp, but stop all
> >     work on it (Lyndon)
> > 2. don't do anything to doc status, but require (encoruage) that id
> >     authors work only on one singalling protocol at a time (Eric).
> >
> > 1 is very close to what was proposed at the mpls wg meeting, 2 is
> > actually a decission to continue develop cr-ldp.
> >
> > /Loa
> >
> > Ong, Lyndon wrote:
> >
> > > This might be actually a reasonable solution, to "cap" the
> > > work on CR-LDP.  I'd have the same concern as Avri with
> > > taking an approved standard and "de-standardizing" it,
> > > although it would help to know if this has been done
> > > before.
> > >
> > > Cheers,
> > >
> > > Lyndon Ong
> > > Ciena
> > >
> > > Sent: Tuesday, July 23, 2002 9:38 AM

---

From: Bala Rajagopalan <[email-masked]>
Date: Wed, 24 Jul 2002 11:05:24 -0400

The problem (at least the way I see it) is that both
protocols satisfy the requirements and neither
OIF nor ITU-T has tried to pick one (and only one) protocol.
In effect, these organizations (IMO) have taken the
path of least resistance, not getting into the messy
issue of selecting "a" protocol. And since the work
is usually done by different groups of people, this
choice of allowing everything is easy, regardless
of what gets finally implemented.

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> Sent: Wednesday, July 24, 2002 1:29 AM
> To: Bala Rajagopalan
> Cc: Loa Andersson; [email-masked]

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 24 Jul 2002 10:59:36 -0700

Hi David,

Actually, SCTP is an alternative that supports message
passing and boundary preservation, plus other features
for reliability and detection of signaling path failure.
It was intended to relieve the application from having to
do continual verification of the signaling path and support
of a backup path.  However, it was being defined at about
the same time as MPLS, so it was never considered as an
alternative for transport of MPLS signaling.  

A reliable UDP was one of the alternatives considered when doing
SCTP, but it still leaves the application to do testing
of the signaling path and message rerouting if that fails, 
and does not have congestion control built in.

Cheers,

Lyndon

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 7:45 AM
To: IETF MPLS List
Subject: Re: initiating a discussion on mpls singaling protocols

As for the rest, TCP is not an appropriate transport for signaling 
protocols in the first place.  RSVP-TE, LDP and CR-LDP all use a 
message-passing mechanism.  They are not designed around streaming data. 
  Use of a streaming protocol means that the protocol has to deal with 
the issue of detecting message boundaries and half-received messages.

Unfortunately, there is no standard for anything resembling reliable UDP 
- that would be ideal.

---

From: Hummel Heinrich <[email-masked]>
Date: Thu, 25 Jul 2002 11:08:58 +0200

What kind of LSPs are we currently able to establish ? Which of the following LSPs
can be established by CR-LDP, RSVP-TE, LDP :

1) p2p     LSP
2) p2mp    LSP
3) mp2p    LSP
4) mp2mp   LSP
5) p2p   H-LSP
6) mp2p  H-LSP
7) p2mp  H-LSP
8) mp2mp H-LSP

Which of the three protocols seems to be suitable for extensions where we don't have a solution yet?

(BTW: In Orlando in 1998 I remember a VPN BOF, which at that time failed  to proceed to a WG, because
of an argument, saying "we cannot do such high level applications before we haven't even solved MPLS Multicast:-(  

Heinrich

-----Ursprüngliche Nachricht-----
Von: Bisewski, Radoslaw [mailto:[email-masked]]
Gesendet: Donnerstag, 25. Juli 2002 10:15
An: 'Giles Heron'; Jothilingam, Vasudevan ""(Vasu)
Cc: IETF MPLS List
Betreff: RE: initiating a discussion on mpls singaling protocols

But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in
common with LDP. After "eliminating" CR-LDP you will still have two MPLS
signalling protocols MPLS LDP and RSVP-TE.

Radek

> From: Giles Heron [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 9:49 PM
> To: Jothilingam, Vasudevan ""(Vasu)
> Cc: IETF MPLS List
> On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote:
> [snip]
> > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be
> > informational RFC.
> > Being said that, there is lots of work going of L2 
> Transportation over MPLS,
> > using LDP.
> 
> LDP != CR-LSP
> 
> Giles
> 
> > Well, even though I am not for that approach of using 
> RSVP-TE and LDP ( two
> > big protocols ??)
> > for L2 transport, we need to see where that goes..
> > 
> > Thanks
> > Vasu
> > 
> > 
> > 
> > 
> > Vasu Jothilingam
> > Lucent Technologies
> > 1 Robbins Rd
> > Westford, MA-01886
> > PH:   (978)-952-7533
> > FAX: (978)-952-7977
> > 
> > 
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Wednesday, July 24, 2002 2:00 PM
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================
>

---

From: "Bisewski, Radoslaw" <[email-masked]>
Date: Thu, 25 Jul 2002 17:02:38 +0200

CR-LDP is functionaly equivalent to RSVP-TE. However the advantage of the
CR-LDP over the RSVP-TE is that CR-LDP is an extension to the existing LDP
protocol.
LDP with CR-LDP extensions gives you one protocol implementation, which
handles both automatic generation of LSP based on routing table and TE. On
the other side ( LDP and RSVP-TE) you will have two different protocols
serving two different purposes. I'm not sure if the second approach (LDP and
RSVP-TE) is the optimal one.

Radek

> Sent: Thursday, July 25, 2002 4:42 PM
> To: IETF MPLS List
> Bisewski, Radoslaw wrote:
> So?  These two serve very different purposes and are not redundant.
> 
> LDP automatically generates LSPs based on the routing table.
> 
> RSVP-TE generates traffic-engineered LSPs based on requests from an 
> ingress router.
> 
> -- David
>

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Thu, 25 Jul 2002 12:21:06 -0400

> RSVP-TE) is the optimal one.

Given that the choice in front of us is (1) LDP + RSVP-TE + CRLDP,
or (2) LDP + RSVP-TE, this is a moot point. No one is discussing
just LDP + CRLDP as a possibility.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 25 Jul 2002 10:18:07 -0700

FYI, 

Following is an excerpt from an article published in the July 2002 IEEE communication magazine called "A proposal for an Alternative Standards Setting process":

"... in the absense of a sound basis for the judgement and decision, the adoption of a particular technology by just one firm may encourage others to follow suit. If this happens, chances are that an inferior technology will be adopted, which may suit the initial adaptor but does not necessarily meet other entities' demands. They in turn, will then make their choices solely based on the initial adaptor's policy decision. Little if any experiment with alternative technologies or systems will occur, which will rapidly be discarded. The DOS operationg system was a case in point: one strong player, IBM, chose this system, which did not really represent the state of the art even at that time, and almost all others followed the suit. Obviously IBM gained significant profits from this developement- as did even more so, Microsoft..."

-Shahram

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 26 Jul 2002 11:57:19 +0530

I am just saying is that adding so much complexity and code to RSVP has only
made it to have 'not more overhead' than CR LDP.

Regards,
Vijay 

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 7:50 PM
To: [email-masked]
Subject: Re: initiating a discussion on mpls singaling protocols

Vijayanand C - CTD, Chennai. wrote:
>
> I accept your argument. However, it finally comes down to saying that
> RSVP-TE is not having more overhead than CR-LDP. Its taken a lot of
add-ons
> and workarounds to RSVP to bring to this level. Thats why the question of
> complexity, implementation and maintenance issues related to software life
> cycle reduction were raised.

The fact that extensions are needed to make it scale doesn't make the 
protocol somehow worthless.  You don't say BGP is trash because version 
1 can't scale to the current size of the internet, do you?

-- David

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 26 Jul 2002 17:37:39 +0530

To add one more point here- by making extensions to RSVP it may have come to
a state where it does nt have 'more overhead' than CR LDP. But should
everyone bother to add so much of stuff to RSVP and then use it than using
CR LDP. At present RSVP-TE may be leading in deployment due to kick start
given by leaders and hence this may not be the right criteria to judge it,
as Shahram also pointed out.The question is which protocol would benefit
everyone in the long run in terms of performance,feature-extensibility(as
Heinrich points out),scalability and  other implementation/maintenance
issues related to software life cycle reduction.

Regards,
Vijay

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 7:50 PM
To: [email-masked]
Subject: Re: initiating a discussion on mpls singaling protocols

add-ons

-- David

---

From: "David Allan" <[email-masked]>
Date: Fri, 26 Jul 2002 11:53:22 -0400

Shahram:

Wasn't 15% although the relationship was linear and not exponential, and
where the argument got heated was comparing the LSH count vs. overall state.
Unstated was if you used per-platform space the amount of state at the
downstream LSRs of each LSH diminished significantly (although still more or
less a linear relationship and probably forced use of liberal label
retention so you didn't need to remember the list of folks who cared about
your label, in other words your state issues got pushed upstream).

Not that I want to start THAT discussion again..... ;-)

cheers
Dave

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 11:15 AM
> To: 'Giles Heron'; [email-masked]
> Cc: [email-masked]
> Giles,
> > I want *both* mp2p LDP and targetted LDP.
> > 
> > I want the former because it:
> > 
> > 1) minimises the number of labels required in the core - O(N) rather
> > than O(N squared).
> > 
> 
> I think Heinrich Hummel demonstrated in the Japan (as 
> predicted by Dave Allan)
> that mp2p (LDP) results only ~15% less states than N^2 mesh. 
> 
> -Shahram 
> 
>

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 29 Jul 2002 17:09:11 +0200

Does this all mean that you are carrying the ER-Hop/ Bandwidth etc from
the egress (root) towards the ingress (head)? Applications?

Bandwidth reservation for all sections of the mp2p merge tree:
It is assumed that the root (egress) knows how much bandwidth is required for the sake of each leaf(ingress).
In compliance with the merging branches, the root may compute the accumulated bandwidth demand for each non-branching tree section. By proper placement of a Nodes-Info-Begin-TLV (which contains the accumulated bandwidth size and also a unique
"sequence number") and of a Nodes-Info-End-TLV (which contains the respective "sequence number" as well), each node 
at the begin, in the middle, and at the end of the particular non-branching tree section will be alerted to make the
appropriate bandwidth reservation.  
Consider some non-branching tree section somewhere in the middle of the tree. The respective TLV-pair will be forwarded
from the root to the nearest node of this section. That nearest node will recognize which child link is of concern, and
will be alerted to make the right bandwidth reservation. The Nodes-Info-Begin-TLV would not be removed before it becomes
placed next to the respective Nodes-Info-End-TLV. I.e. it may alert all the nodes of this section. Thereafter, both TLVs will drop out.

/Sumit

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 29 Jul 2002 18:03:33 +0200

NO, the savings are much more. They are about 85 % reduction, so that 15 % remains.( I will not talk down these savings)
However, 0.15  * O(n**2) will still be far too much, if n is big enough.

Note that method (4) as of draft-hummel-mpls-n-square-investigations-00.txt also uses merging H-LSPs as to reduce the
costs at the PEs, e.g. down to 0.15 * O(n**2). 

But I also pointed out that even this is not good enough, if n = 7500 for example. For VPNs of such size, we should even form groups of sites (e.g. all sites within one city form a group)
and may have:
a) a partial mesh of elementary LSPs (which form a tree, a ring, a ring of trees, a tree of rings,or a chessboard grit)
b) a full mesh of hierarchical LSPs between the groups of sites
c) a full mesh of hierarchical LSPs between the sites of each group of sites

In order to accomplish effective full mesh connectivity, it may be appropriate to advertise all these LSPs (their ingress
and their egress, as well as their starting labels, etc.) - roughly spoken.
 
Of course it will take more labor, more conceptual thinking. E.g. so that the VC-label handling is integrated rather than
an "abuse" :-)

Heinrich

-----Ursprüngliche Nachricht-----
Von: Shahram Davari [mailto:[email-masked]]
Gesendet: Freitag, 26. Juli 2002 17:15
An: 'Giles Heron'; [email-masked]
Cc: [email-masked]
Betreff: RE: initiating a discussion on mpls singaling protocols

Giles,

> 1) minimises the number of labels required in the core - O(N) rather

I think Heinrich Hummel demonstrated in the Japan (as predicted by Dave Allan)
that mp2p (LDP) results only ~15% less states than N^2 mesh. 

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jul 2002 09:05:42 -0700

Ok, my mistake.

-Shahram

> Sent: Monday, July 29, 2002 12:04 PM
> To: Shahram Davari; 'Giles Heron'; [email-masked]
> Cc: [email-masked]
> NO, the savings are much more. They are about 85 % reduction, 
> so that 15 % remains.( I will not talk down these savings)
> Note that method (4) as of 
> draft-hummel-mpls-n-square-investigations-00.txt also uses 
> merging H-LSPs as to reduce the
> But I also pointed out that even this is not good enough, if 
> n = 7500 for example. For VPNs of such size, we should even 
> form groups of sites (e.g. all sites within one city form a group)
> and may have:
> a) a partial mesh of elementary LSPs (which form a tree, a 
> ring, a ring of trees, a tree of rings,or a chessboard grit)
> In order to accomplish effective full mesh connectivity, it 
> may be appropriate to advertise all these LSPs (their ingress
> Of course it will take more labor, more conceptual thinking. 
> E.g. so that the VC-label handling is integrated rather than
> an "abuse" :-)
> 
> 
> Heinrich
> 
> 
>