Subject: RE: initiating a discussion on mpls singaling protocols

From: "David Allan" <[email-masked]>
Date: Thu, 18 Jul 2002 22:49:42 -0400

Swimming upstream ;-)

I think it is premature in the GMPLS space to drive CR-LDP into
informational. It is not clear to me that soft state is an appropriate
solution when considering the holding times for SONET/SDH and optical trails
irrepsective of how wonderful refresh reduction is. RSVPs starting point is
the opposite end of the spectrum from the POV of flow characteristics.

I have no issue with the pragmatics of the packet space.

cheers
Dave

---

From: Yangguang Xu <[email-masked]>
Date: Fri, 19 Jul 2002 09:35:30 -0400

Hello,

Sorry, a side topic. :-)

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?

Thanks,

Yangguang

---

From: David Charlap <[email-masked]>
Date: Fri, 19 Jul 2002 10:18:39 -0400

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

It is possible to safely use a very large refresh timer, but only when 
refresh reduction and hello are in use on all peers.  The message-id 
part of refresh reduction will allow for retransmission of lost packets, 
and hellos will detect soft failures.

-- David

---

From: George Swallow <[email-masked]>
Date: Fri, 19 Jul 2002 11:54:05 -0400

Yangguang -

> Will these help, or they make things worse?

So called hard-state also depends on refreshes.  LDP messages depend
on the TCP connection staying up to maintain their validity.  The TCP
connect sends keepalives if there is no other traffic.  In effect, a
single message (keepalive) refreshes all of the connections.

Summary refresh is a mechanism to allow a single message to refresh
many connections - you can fit about 300 in an MTU of 1500.  So you
want to *enable* refresh reduction rather than disable it.  The
question of refresh timer length is tied to the frequency at which you
want to send the refresh messages.

The refresh reduction also gives you reliable delivery.  So if you set
the timers long, you can reliably deliver a tear message if you need
to remove the state.

...George

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

---

From: Yangguang Xu <[email-masked]>
Date: Fri, 19 Jul 2002 13:29:31 -0400

George,

This topic may belong to CCAMP, whatever...

I agree with what you and Dave said. Indeed, I don't worry about the refresh
part of the soft state too much. It's useful and can be done efficiently.

Yet, no matter hard state or soft state, in optical network, a data plane
connection should be torn down explicitly by user/operator. i.e. if the
connection states in the control plane have errors, rather than sending
PathErr/PathTear to tear down the data path, a trap or alarm should be raised to
notify network management system. Instead of changing the protocol's default
behavior, I was thinking about how to just manipulate configuration to meet this
requirement. Now it seems to me that's not a good idea.

Thanks,

Yangguang