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

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 24 Mar 2005 16:18:04 -0500

> Richard,
>
> Somehow I missed reading your email when I was crafting my own. I see 
> that we agree on the various methods that could be deployed (and I 
> apologize for repeating your arguments). I have one question, though. 
> You define Traffic Engineering as optimizing resource utilization and 
> network performance. Subsequently, you discuss the mechanisms to find 
> optimal paths. Finally, you mention that BT does not need TE.
>
> However, even if you are not interested in finding the *optimal* path, 
> you still need to find a path with sufficient resources. How would you 
> do that?

	Why are you making the assumption that you need sufficient
resources to be signaled?

	--Tom

>
> Peter
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Thursday, March 24, 2005 11:07 AM
>> To: [email-masked]; [email-masked];
>> [email-masked]
>> Cc: [email-masked]
>> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
>>
>>
>> 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
>> 	
>>
>>
>