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

From: "Nurit Sprecher" <[email-masked]>
Date: Thu, 31 Mar 2005 11:15:19 +0200

Hi Richard,
I already thought about such devices. 
The ingress node can calculate only part of the explicit route and let
the S-PEs extend the explicit route using their Links state protocols
and CSPF algorithm. The 'CSPF algorithm' at the cheep U-PE devices can
be atrophied and have a static configuration for the next hop. It may
also have a static configuration for a redundant next hop (for the
global protection of the MS-PW). The next hop (i.e. the S-PE) probably
supports IGP-TE and CSPF and can extend the explicit route.
Best regards,
Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, March 31, 2005 11:08 AM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

Nurit,
 
Your suggestion to advertise tunnel LSPs as FA-LSPs is one possible
solution to MS-PW routing, but as Ben points out below, it does not
address all service provider requirements. For example, in the
intra-provider case, U-PEs may be low cost devices with limited
processing/memory resources that do not support link state routing
protocols.
 
Regards,
Richard

	-----Original Message----- 
	From: [email-masked] on behalf of
[email-masked] 
	Sent: Wed 30/03/2005 10:40 
	To: [email-masked] 
	Cc: 
	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

	Nurit,
	
	One comment, see below (I've snipped the rest)...
	
	[Richard]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.
	
	[Nurit] However, this has been addressed in the MPLS WG, the LSP
Hierarchy draft. \[Nurit]
	
	I'm not sure how relevant (or useful) the LSP hierarchy draft is
to the generic case of MS-PWs (I can see how it helps in some specific
use cases/deployment scenarios).  For a start:
	
	1)[Minor]LSP hierarchy does not explicitly address the problem
of routing & route calculation for cases where the 'tunnel' is not
MPLS/GMPLS.
	
	2)[Major]LSP hierarchy does not recognise/allow functional
decoupling and a client/server relationship as described in G.805
between the PW layer and the MPLS layer (FA are advertised into the same
instance of the IGP forcing the PW and MPLS layers to use the same
instance of the IGP).  This can cause headaches in a number of
situations, e.g.(i) it sounds like the peer model to me and forcing
operators to use the peer model in order to be able to use MS-PWs is a
very bad idea IMO.  (b)The server (MPLS tunnel LSPs) layer network and
the client (MS-PW) layer network may be owned by different
operators/commercial entities and the sharing of a single routing
instance may not be acceptable/possible to one or other party due to
commercial/legal/regulatory reasons etc.
	
	I believe the issue of properly addressing routing and
reachability in a MS-PW layer network is not as simple as it may first
appear (essentially we are creating a new layer network with MS-PWs, we
are not just adding a couple of 'bells and whistles' to SS-PWs) and
needs careful consideration (including the commercial/economic aspects
as well as the technical ones) if we want to avoid creating a mess that
costs a fortune to operate/manage/maintain/fix.
	
	Ben
	
	_______________________________________________
	pwe3 mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/pwe3