The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

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

Developing a new transport for signalling  would be much beneficial than
doing it separately for each signalling protocol.


Regards,
Vijay

-----Original Message-----
From: David Charlap [mailto:david.charlap@marconi.com]
Sent: Wednesday, July 24, 2002 8:15 PM
To: IETF MPLS List
Subject: Re: initiating a discussion on mpls singaling protocols


Vijayanand C - CTD, Chennai. wrote:
> TCP being a relaible transport protocol is meant to do just that. It can
and
> has been optimised repeatedly for this purpose. The presence of TCP is
> almost default in all the stacks. So, there is no need to duplicate a part
> of its functionality in another protocol and try to optimise it repeatedly
> in a new thread. Trying to build a semi reliable transport layer inside
> RSVP-TE with all its paraphenelia to make it harder is another form of
> duplication so to speak. Also, refreshing a number of LSPs even through
> summaries is avoided by a single keep alive in CR LDP.

Thanks for changing the subject here.

You were talking about protocol complexity, not implementation stability.

Of course a new protocol implementation will be less stable than 
something 20 years old.  Does this mean we should avoid developing 
anything new ever again?

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.

The message-ID part of RSVP refresh reduction is designed to fill this 
void.  Packets can't be half-received, and message boundaries are 
preserved.  Retransmission is on a per-message basis instead of for the 
entire flow, so one dropped message doesn't cause all subsequent 
messages to back up waiting for the retransmission.  It also recognizes 
the fact that not all messages need to be delivered reliably, and allows 
RSVP to not use the mechanism for those messages that don't result in 
state changes.

With regard to refreshing, you don't seem to appreciate what the refresh 
reduction extension buys.  There is no need to generate summary 
refreshes every 30 seconds.  As I have said before, when refresh 
reduction and hellos are both in place, there is no need for frequent 
refreshes.  Under this circumstance, you can set the refresh interval to 
something on the order of hours, or even days without any ill effect. 
How is this have any more overhead than what CR-LDP does.

-- David