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

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

Hi Sasha,

As I already stated, TE MS-PWs can be useful also for intra-provider
cases, to help in the TE over inter-area cases. In a TE over multi-area
case, the core may be built from S-PEs, each function as an IGP ABR.

Best regards,

Nurit.

  _____  

From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Thursday, March 31, 2005 3:12 PM
To: 'Florin Balus'; Nurit Sprecher; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

Hi all,

One conclusion that IMO can be reached from some emails on this thread
is that inter-provider and intra-provider use cases are different. 

The immediate step that IIMHO is required is explicit mapping of generic
MS-PW requirements (as they appear in the currrent draft) to specific
use cases. This would presumably facilitate making the requirements
themselves more specific.

Regards,

                                  Sasha Vainshtein

email:                         [email-masked]
<mailto:[email-masked]> 

phone:                       +972-3-7569993 (office)

fax:                            +972-3-6487779

mobile:                      +972-52-8674833 

	-----Original Message-----
	From: Florin Balus [mailto:[email-masked]]
	Sent: Thursday, March 31, 2005 2:26 PM
	To: Nurit Sprecher; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

	Nurit, 
	In the Intra-Provider case we are discussing below, what good
does it do to mention all the TE features if all you have is just one
core MPLS domain: i.e. U-PE1 - "cheap domain" (static etc)- S-PE1 - core
MPLS domain - S-PE2 - "cheap domain" (static etc) - U-PE2?

	Regards, 
	Florin 

	> -----Original Message----- 
	> From: [email-masked] [mailto:[email-masked]] On 
	> Behalf Of Nurit Sprecher 
	> Sent: Thursday, March 31, 2005 4:15 AM 
	> To: [email-masked]; [email-masked]; 
	> [email-masked] 
	> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt 
	> 
	> 
	> 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 
	>       
	> 
	> 
	> 
	> _______________________________________________ 
	> pwe3 mailing list 
	> [email-masked] 
	> https://www1.ietf.org/mailman/listinfo/pwe3 
	> 
	> 

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