Subject: [mpls-tp] SS-PW over inter-provider LSP

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 27 Jul 2010 17:20:12 +0530

Hi,
As per http://www.ietf.org/MPLS-TP_overview-22.pdf (MPLS Architectural
considerations for a Transport Profile dated April18, 2010, slide no. 56)

Slide Title: SS-PW over inter-provider LSP (LSP, TCM-LSP & PW OAM), there
are seperate LSPs in the provider-A (LSP path: A-B-C),
provider-B (LSP path: D-E-F) and between provider-A and provider-B (LSP
stitching: C-D)

>From this slide, it is very clear that same SS-PW can exist across providers
A and B.

Can we have a single LSP (LSP path:A-B-C-D-E-F) traversing through
provider-A and provider-B in the MPLS-TP deployment instead of segmented
LSPs?

--
Best Regards,
Venkatesan Mahalingam.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 27 Jul 2010 14:24:18 +0200

Venkat,
 
The E2E LSP is a single LSP with endpoints in A and F. The text on the right
states "From DP perspective, LSP stitching is a normal label swap
operation". The E2E LSP is a Multi-Hop/Segment service LSP carrying a
Single-Segment PW. The E2E LSP is monitored in provider-A and provider-B
networks using TCM-LSPs (SPMEs); provider-A and provider-B can now determine
independently of each other if the transport through their networks
introduces faults and/or packet loss in the E2E LSP.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of venkatesan mahalingam
Sent: dinsdag 27 juli 2010 13:50
To: [email-masked]
Subject: [mpls-tp] SS-PW over inter-provider LSP

Hi, 

A and B.

--
Best Regards,
Venkatesan Mahalingam.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jul 2010 13:25:03 +0100

On 27/07/2010 12:50, venkatesan mahalingam wrote:
> Slide Title: SS-PW over inter-provider LSP (LSP, TCM-LSP & PW OAM), 
> there are seperate LSPs in the provider-A (LSP path: A-B-C),
> provider-B (LSP path: D-E-F) and between provider-A and provider-B 
> (LSP stitching: C-D)
> From this slide, it is very clear that same SS-PW can exist across 
> providers A and B.
> provider-A and provider-B in the MPLS-TP deployment instead of 
> segmented LSPs?

Yes.

However, suppose the link goes SP-A, SP-B.... , SP-Y, SP-Z

With an end to end LSP, SP-A and SP-Z need to agree the PW label, 
whereas with a MS-PW, SP-A talks to SP-B about the LSP label (which they 
need to do anyway in the end to end LSP case) AND the PW label and so on 
pairwise to SP-Z. However SP-A and SP-Z do not need to talk.

Also SP-A and SP-Z need the same LSP OAM configuration with an end to 
end LSP.

So both models are allowed and it's a matter of operational preference 
which is chosen.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jul 2010 15:17:16 +0100

Another property we loose by using an end to end LSP in place of a 
MS-PW is aggregation.

Remember we started with SS-PW and invented MS-PW at the request of 
network operators to address scaling and manageability issues.

- Stewart

On 27/07/2010 13:25, Stewart Bryant wrote:
>> As per http://www.ietf.org/MPLS-TP_overview-22.pdf (MPLS 
>> Architectural considerations for a Transport Profile dated April18, 
>> 2010, slide no. 56)
> whereas with a MS-PW, SP-A talks to SP-B about the LSP label (which 
> they need to do anyway in the end to end LSP case) AND the PW label 
> and so on pairwise to SP-Z. However SP-A and SP-Z do not need to talk.
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 27 Jul 2010 23:01:09 +0200

Stewart,

Aggregation is fully supported by aggregating service-LSPs into
transport-LSPs. Transport-LSPs aggregate MS-PWs, service-LSPs and HVPLSs.
Replacing a MS-PW by a SS-PW within a service-LSP doesn't introduce any
limitation to aggregate. Note that the service-LSP has been introduced
during the development of MPLS-TP and was not available/in mind when the
MS-PW need was identified.

Using service-LSPs to carry SS-PWs will simplify the MPLS-TP OAM design as
there will not longer be a need to develop MPLS-TP PW OAM. And consequently
there is no need to mandate the presence of the CS header in MPLS-TP.

Use of SS-PW carried inside a service-LSP provides a less complex MPLS-TP
architecture.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: dinsdag 27 juli 2010 16:17
To: [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

  Another property we loose by using an end to end LSP in place of a MS-PW
is aggregation.

Remember we started with SS-PW and invented MS-PW at the request of network
operators to address scaling and manageability issues.

- Stewart

On 27/07/2010 13:25, Stewart Bryant wrote:
>> 2010, slide no. 56) Slide Title: SS-PW over inter-provider LSP (LSP, 
>> TCM-LSP & PW OAM), there are seperate LSPs in the provider-A (LSP 
>> path: A-B-C), provider-B (LSP path: D-E-F) and between provider-A and 
>> provider-B (LSP stitching: C-D) From this slide, it is very clear 
>> that same SS-PW can exist across providers A and B.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 09:45:23 +0200

Stewart,

Your statement
> and so on pairwise to SP-Z. However SP-A and SP-Z do not need to talk.
is not correct. 

The SP-A and SP-Z in a MS-PW need to agree the MPLS-TP MS-PW OAM
configuration, and as such have to talk.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: dinsdag 27 juli 2010 23:01
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

Stewart,

Regards,
Maarten

-----Original Message-----

- Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 08:23:48 -0400

In message <[email-masked]>
> Use of SS-PW carried inside a service-LSP provides a less complex MPLS-TP

The scaling problem occurs when you have a very large number of metro
and a smaller number of LSR at the next tier of the network (regional,
core, whatever).  Initially customers request service based on PW and
some metros are interconnected.  As the service suceeds, the network
gradually approaches a full mesh of T-LDP adjacencies among the metro
LSR.  At some point signaling aggregation is needed to reduce the
number of T-LDP peers at a given metro LSR.  This is what motivates
MS-PW, not a forwarding consideration.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jul 2010 15:28:14 +0300

Curtis,
I agree with your comment.
I would just like to add that, in addition to scalability of SS-PW signaling, there is the need to expose the regional/core topology to metro nodes if/when TE-ed tunnels were required to carry the PWs.
MS-PW technique allows the operator of the regional/core network to hide this information from the metro operators.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Wednesday, July 28, 2010 2:24 PM
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

Curtis