Subject: RE: TCP/bi-directioanl flows

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Thu, 9 Sep 1999 16:33:51 -0500

> >  I have a question regarding explicit routing. I understand that when a
> > connection is required with explicit routing, *-LDP is used to
> > establish LSP. But what about a bi-directional flow as in TCP or any
> > network management utility like ping. 
	[Ashwood-Smith, Peter [CAR:CF57-I:EXCH]]  

	   MPLS flows are currently only unidirectional so regardless of how
	you establish the LSP  (LDP,CR-LDP,etc.) the traffic only goes from
the
	source to the destination. Reverse traffic either requires its own
LSP or must 
	go normal IP. There have been some proposed mechanisms to allow 
	traceroute to show MPLS paths but they are not currently in any of
	the drafts going through last call. Unless I've missed something. 

>  The client
> > can be smart enough to request a specific path, but what about the
> server,
> > should it follow the hop-by-hop ( as it is a point-to-multipoint )  .
	[Ashwood-Smith, Peter [CAR:CF57-I:EXCH]]  

	Initially its going to be the backbone AS's that will be creating
and
	terminating LSPs. Thus a client and server will not participate in
MPLS
	signalling until other problems are solved. Inter AS traffic
engineering for
	example which we are starting to think about drafting. Both PNNI and
	other proprietary protocols have solutions to this but this will
have to
	be hashed out at the IETF, probably next year. 
	Its also a LOT of signalling to have every client launching label
	requests so aggregation at some point is required to keep things
from
	getting out of wack.

> > Does it scale?
	[Ashwood-Smith, Peter [CAR:CF57-I:EXCH]]  
	Its a question of memory, CPU and bandwidth. Each LSP imposes
certain 
	measurable loads on every switch it traverses. The problem is not so
much
	having very large numbers of LSPs as dealing with them all during
times of
	failure. One of the things about path oriented routing is that it
will respond to
	an overload of LSPs by making them wait for rerouting etc. so it
does degrade
	rather nicely as long as the messaging protocols are flow controlled
properly
	and don't interfere with other more critical control protocols.

	Personally I think we will start with fairly coarse aggregated LSPs
not crossing
	AS boundaries, then we will work on the AS boundary, then as we get
more and
	more CPU and memory to play with and can make the aggregations
smaller and 
	allow more LSPs. In this manner we can trade off precision of
traffic engineering
	for scalability. 

	Cheers,

	Peter Ashwood-Smith