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

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

Please see my mail to Florin.

Nurit.

  _____  

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

Nurit,

Please see a brief comment inline.

Regards,

                       Sasha

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

	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.
	[[Sasha]] Sorry I do not understand that. Which IGP do you have
in mind: IGP running within each provider domain or some common IGP
running between all the S-PEs? The 2nd case probably matches the LSP
Hierarchy concept but has its own restrictions, while the 1st one should
be probably reserved (i.e., only ABRs are allowed to acr as S-PEs).

	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