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

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

Hi Florin,

>From the abstract of the requirement draft:

"This document describes the necessary requirements to allow a service
provider to extend the reach of pseudo-wires across multiple domains. 

These domains can be autonomous systems under one provider
administrative control, IGP areas in one autonomous system, different
autonomous systems under the administrative control of two or more
service providers, or administratively established pseudo-wire
domains...". 

I am surprised to learn that you think that this is as you wrote below:
" point to introduce additional "jumping points" (S-PEs) just to justify
the need for MS-PW TE".

I treat the requirements very seriously and take them into
consideration. I also send comments to the requirement draft. I accepted
it as a WG document. I would like to believe that every one that
contributes to this specific discussion is familiar with the requirement
draft, the solution draft and with the TE requirements, mechanisms and
protocols.

Best regards,

Nurit.

  _____  

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

Hi Nurit,

See in-line...

	-----Original Message-----
	From: Nurit Sprecher
[mailto:[email-masked]] 
	Sent: Thursday, March 31, 2005 7:32 AM
	To: Balus, Florin [CAR:6955:EXCH]; [email-masked];
[email-masked]
	Cc: Nurit Sprecher
	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

	Hi,

	The scenario you are talking about is just an example. We can
have an inter provider network. 

	Note that as I already specified in a previous mail, also in the
core itself we can occupy multiple S-PEs for TE over inter-area sake. TE
signaling over multiple areas is not such a simple and trivial case
(since TE information is not distributed across areas). There are some
mechanisms to overcome the issue and the MS-PWs solution can be also
used to overcome it and provide a better and maybe more efficient
solution. TE Tunnels are established at each area, and the ABRs would
function as S-PEs. 

	FB: Well you see, it should be the horse that pulls the chariot
not the other way around! :) 

	MS-PWs were introduced to solve specific issues and as a result
the size of the PW Domain is determined by these specific issues. There
is no point to introduce additional "jumping points" (S-PEs) just to
justify the need for MS-PW TE: e.g. if I could afford to traverse the
Core MPLS domain with one signaling and tunnel jump then it is much
better to let that tunnel to re-route, perform TE then to handle
individually each PW segment!

	That is why it is so important to define the problem space
before jumping to conclusions on the extent of functionalities we
require from the MS-PW signaling protocol.

	Best regards,

	Nurit.

  _____  

	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