Subject: RE: draft-raggarwa-rsvpte-pw-01.txt

From: [email-masked]
Date: Thu, 24 Mar 2005 16:06:33 -0000

Nurit,
 
Please can you expand on what you mean by TE MS-PW?
 
There are a number of definitions of what TE means but I would say that the purpose of TE is to increase resource utilisation and network performance, and to guarantee resources for high priority traffic under failure conditions.
 
To achieve this I think there are two key functions:
 
[1] Use of offline network monitoring/modelling techniques or CSPF to calculate optimal paths through the network.
 
[2] Use of mechanisms/techniques (e.g. signalling of LSPs with explicit paths) to ensure traffic follows the optimal paths determined in [1].
 
Optimal path calculation for tunnel LSPs is based on the physical/logical link topology. To perform optimal path calculation for MS-PWs, then the calculations need to be based on the tunnel LSP topology, i.e. the bandwidth available in each tunnel LSP.
 
If we want to support end-to-end path computation at the source using CSPF for MS-PWs, then I believe we will need to advertise tunnel LSPs as FA-LSPs into the TE database. An alternative would be to perform the end-to-end MS-PW path calculation using offline tools based on per tunnel LSP utilisation information. In both cases we need a setup mechanism with an ERO capability to ensure traffic follows the optimal path.
 
An alternative method of providing path optimisation would be to perform hop-by-hop tunnel selection. Hop-by-hop tunnel selection first of all would require reachability information, (i.e. knowledge of which tunnels can be used to reach the destination). Also, in order to avoid following the shortest path, per hop policies would be required in order to select the most appropriate tunnel (e.g. always choose the tunnel with the most bandwidth available or always choose a red tunnel over a blue tunnel). Hop-by-hop CAC would be required to check at each hop that bandwidth is available, and crankback would be needed for cases where the next hop doesn’t have a tunnel available that meets the MS-PW resource requirements. 
 
This approach makes the assumption that reachability information is available, and this requires route calculation based on the tunnel LSP topology. There are a number of ways route calculation based on the tunnel LSP topology could be performed, but this is a problem that has not yet been addressed within PWE3 or L2VPN. An alternative to route calculation based on the tunnel LSP topology would be to use flooding, which is one of the approaches proposed in “draft-shah-bocci-pwe3-ms-pw-signaling-00.txt”.
 
From my own perspective, based on a BT specific network topology, I do not need TE at the MS-PW layer. The core (with S-PEs at the edge) will be constructed using TE-LSPs which will take care of core network resource utilisation and provide protection against core failures. As U-PEs are likely to be dual homed to S-PEs I might perform some load balancing, but there is no need for TE. Therefore, the MS-PW setup mechanism needs to support CAC and backup MS-PWs, but does not need to support MS-PW TE.
 
Regards,
Richard

	-----Original Message----- 
	From: [email-masked] on behalf of Nurit Sprecher 
	Sent: Thu 24/03/2005 07:17 
	To: Thomas D. Nadeau; Stewart Bryant 
	Cc: pwe3 
	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

	Hi Tom,
	
	We should distinguish between MS PWs and SS PWs.
	The protocol that we have is appropriate for non-TE MS PWs and also for
	SS PWs (both TE and non-TE). However for TE MS PWs it is not appropriate
	because the requirements of the TE MS PW should be signaled such that
	the S-PEs can use the information to select the appropriate Tunnel/link
	for the PW. For example, to select a Tunnel that its egress is hop
	through which the MS PW should transmit (fro policy sake for example), a
	Tunnel that has enough BW, and support the required Diffserv-TE class,
	that its traffic priority is not smaller than the priority of the PW,
	that the Tunnel is protected with mechanism that provides up to 50ms
	restoration time in case of a failure, etc. I think that the (only)
	example above indicates that there are "significant advantage to
	signaling PWs using an alternative means". So maybe now you should
	"think otherwise" as you said.
	
	The natural protocol that already provides us with this capability is
	the RSVP-TE protocol (which is already used and deployed for TE
	Tunnels). As I already stated, it should only be extended to support the
	PW identifier (PW ID/Type) and the control word, which is a very little
	extension (especially relatively to the extension that LDP protocol
	should go through to support the signaling of the TE information).
	
	Nurit.

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of
	Thomas D. Nadeau
	Sent: Wednesday, March 23, 2005 5:41 PM
	To: Stewart Bryant
	Cc: pwe3
	Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	
	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA1

	        Personally speaking, I don't think that it is useful
	for the WG to spend time and effort re-inventing
	the wheel, so to speak, which is what this draft
	represents. We already have a protocol for
	signaling PWs that works, and is deployed. If
	there were some significant advantage to signaling
	PWs using an alternative means, I would think
	otherwise, but it seems this is just being proposed
	as an alternative means for achieving the same
	end result.
	
	        --Tom

	> At IETF62 the authors of
	>
	> Setup and Maintenance of Pseudowires using RSVP-TE
	> ftp://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-01.txt
	>
	> asked for the draft to become a WG draft.
	>
	> What is the view of members of the PWE3 WG?
	>
	> Stewart
	>
	> _______________________________________________
	> pwe3 mailing list
	> [email-masked]
	> https://www1.ietf.org/mailman/listinfo/pwe3
	>
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.2.4 (Darwin)
	
	iD8DBQFCQY4dHwfkLUURkkwRAgbtAJ9Bpc/zSm0TungLQ/LOQOD8VXDr+ACfXkWS
	obq/1BEDNhqeTW+u8DzaYGU=
	=s7XE
	-----END PGP SIGNATURE-----
	
	_______________________________________________
	pwe3 mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/pwe3

	_______________________________________________
	pwe3 mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3