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

From: David McDysan <[email-masked]>
Date: Thu, 24 Mar 2005 13:11:28 -0500

I believe that this description covers the access metro and the scaling via
hierarchy use cases in the MS-PW requirements. In these simpler topologies,
some limited crankback with minimal extensions to LDP appears viable.
However, in more complex topologies, such as inter-AS and inter-provider, a
more sophisticated and capable protocol, RSVP-TE, will be needed. (Note, if
we actually get switched L2 services working across providers, this will be
the first time since X.75!)

I suggest that centralized computation or distributed hop-by-hop and
out-of-band versus in-band (except as dictated by the switched technology)
not be stated as requirements, but could be mentioned as local
implementation decisions. 

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [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
> 	
> 
>