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

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Mar 2005 16:48:28 -0500

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
[snipped].
> >
> > 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
> 

Tom,

I am not sure how to interpret your question. I did not use the word "signaled" and did not assume that signaling would play a role. 

This is the issue: Assume that there is an infrastructure with pre-established PSN Tunnels between U-PEs and S-PEs and assume that these PSN Tunnels have certain QoS properties. Based on those QoS properties, a certain number of PWs can be set up through a PSN Tunnel. However, with an increasing number of PWs there may be a point at which the PSN Tunnel is "full" and can not support additional PWs. How do you know? Is there an off-line tool that keeps track? Is there a protocol like OSPF-TE that allows nodes to advertise residual bandwidth on PSN Tunnels? Do the PEs themselves keep track? But if so, how would an ingress PE know which route to take?

There are several solutions (mentioned in Richard's and my emails). Which one is most attractive to BT?

Does this help?

Peter 
 
> 
> 
> >
> > 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
> >> 	
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFCQy6MHwfkLUURkkwRAigKAJ9nGKDlhhsAPy3Dnv/vTJfbn/jIjwCfazjr
> Z9E6fQzZNFpLmrqX1rAndDg=
> =7Cks
> -----END PGP SIGNATURE-----
>