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

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2005 15:36:38 +0200

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:                          <mailto:[email-masked]> [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]
<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