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

From: "Florin Balus" <[email-masked]>
Date: Thu, 31 Mar 2005 09:59:33 -0500

Hi Nurit,
See in-line...

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

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...".  

FB: The important part that we should focus on is the word domains which
should be actually read as (SS-)PW Domains: i.e. they could be traversed by
just one signaling, one tunnel "jumps". These PW Domains are planned by
Service Providers based on the challenges of running regular PWs from one
endpoint to the other. What the above statement says is that the PW Domains
could be any one of these Routing domains or none of them: e.g. they could
be chosen based on the split in Administrative/PSN domains and/or based on
which devices could handle the best the role of S-PEs.

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". 

FB: Please answer in-line, to preserve the whole context of my reply. 

The important point I was making is that in all the Intra-Provider cases I
experienced, the existing MPLS core is treated as one (SS-)PW Domain. I
personally didn't learn about any (MH PW) issues that will require splitting
this domain further (scalability or administrative separation etc)... This
PW Domain could be one/multiple IGP domains (e.g. OSPF areas) and the ABRs
could be different/same with the S-PEs. 

That pretty much meant the scenario you were describing for Intra-Provider
network (U-PE1-"cheap PW domain (e.g static)" - etc) is not the good one for
making the case for TE across PW domains. 

That is because what we have in our hands is in reality: 

U-PE1-"cheap PW domain (e.g static)" - S-PE1-Core PW Domain (MPLS)-S-PE2 -
"cheap PW domain (e.g static)" - U-PE2.  

There is no TE path to be chosen/re-routed inside the Core MPLS domain. The
TE tunnel(s) between S-PE1 and S-PE2 does that at once for 100s of PWs. We
just require to find the next S-PE gateway (S-PE2) or eventually decide
between S-PE2 and alternate gateway (S-PE2' ).

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. 

FB: I actually treat the requirements very seriously myself. I was just
enforcing the point that many people made on the PWE3 list and in the
session that we need to go a step further and map the list of different
requirements to use cases so that we can have a much better view of the
problem space.

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]
<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]
<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
<https://www1.ietf.org/mailman/listinfo/pwe3>  
>       
> 
> 
> 
> _______________________________________________ 
> pwe3 mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>  

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