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

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Aug 2010 12:04:17 -0400

In message <[email-masked]>
Stewart Bryant writes:
>  
> Another property we loose by using an end to end LSP in place of a
> MS-PW is aggregation.

If you mean control plane aggregation then yes.  Either MS-PW or
hierarchical LSP ends up with a label swap at the aggregation point
but MS-PW avoids a very large number of T-LDP sessions at the T-PE
that would be required with SS-PW.

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

Yes.  Success gradually led to scaling issues that are easily and
elegantly solved with MS-PW.

> - Stewart

Curtis

> On 27/07/2010 13:25, Stewart Bryant wrote:
> >
> >  On 27/07/2010 12:50, venkatesan mahalingam wrote:
> >> 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?
> >
> > 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: Maarten Vissers <[email-masked]>
Date: Tue, 10 Aug 2010 14:33:57 +0200

Curtis, Stewart,

In an MS-PW the endpoints in the T-PE have to exchange information with
respect to e.g. the type of client and its encapsulation format that the
MS-PW will carry and configuration of MPLS-TP PW OAM functions, e.g. MEG ID
and if pro-active packet loss measurement is supported. This information is
important only for the endpoints and intermediate S-PEs should not be
bothered by it. Furthermore, if an Ethernet PW carries a bundle of e.g.
C-Tagged VLANs with different VIDs on the UNIs the endpoints have to agree
on the C-VID values that are used between the MS-PW endpoints and how these
relate onto the C-VID values on these UNIs.

With MS-PW and SS-PW endpoints having to agree on this type of client
mapping information and OAM config information, what problem is introduced
by requiring that this set of information includes agreeing on a SS-PW label
value?

Isn't the PW label value a representation of the type of client and its
encapsulation format, i.e. information that must be exchanged between the
two endpoints either way?

I have understood that there is a demand for bundled E1 services (e.g.
4xE1). To support this, 4 TDM PWs are mapped into a (bundled service) LSP in
the T-PE nodes. The LSP is a multi-segment LSP and the four PWs are SS-PWs.
Both LSP endpoints need to agree on the PW label values for these four TDM
PWs, but those PWs do not need any MPLS-TP PW OAM; the bundled service is
monitored using LSP OAM. GMPLS should be able to take care of the set up of
this LSP and could also be used for the configuration of the two endpoints,
including the four SS-PW labels.

For the case of a service-LSP, the client mapping and endpoint configuration
information will be carried via GMPLS (is this correct?); e.g. transport of
4 MPLS LSPs via one service-LSP will require to agree on the values of the 4
LSP labels between the endpoints of the MPLS-TP network (i.e. between
MPLS-TP T-PE nodes supporting MPLS LSP services). 
If we use a service-LSP with a single SS-PW inside it, we could also use
GMPLS to carry the client mapping and endpoint configuration. The SS-PW does
not need any PW OAM; the service is monitored using the service-LSP OAM.

If the client mapping and endpoint configuration information (including MPLS
LSP label value assignments) associated with a service-LSP will not be
carried via GMPLS, but instead via the MPLS control plane, then we could get
a large set of MPLS control plane edge-to-edge relationships (assume that
many MPLS LSPs are transported via a large multi-domain MPLS-TP network),
similar as we are discussing for T-LDP controlling SS-PWs carried inside a
similar service-LSP in a large network.

If there would be a T-LDP scaling problem if we whould use only SS-PWs
carried inside a service-LSP between MPLS-TP T-PE nodes, then I expect a
similar scaling problem for MPLS control plane case when we would carry one
or more MPLS LSPs inside a service-LSP between MPLS-TP T-PE nodes.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: maandag 9 augustus 2010 18:04
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

If you mean control plane aggregation then yes.  Either MS-PW or
hierarchical LSP ends up with a label swap at the aggregation point but
MS-PW avoids a very large number of T-LDP sessions at the T-PE that would be
required with SS-PW.

> network operators to address scaling and manageability issues.

Yes.  Success gradually led to scaling issues that are easily and elegantly
solved with MS-PW.

Curtis

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Aug 2010 10:48:35 -0400

Maarten,

You've provided interesting examples and reasoning but they may not
match the scaling problem and requirements that have motivated going
from SS-PW to MS-PW and the further mapping to scalable MPLS-TP
deployment in that environment.

E1 and T1 is legacy and its nice that it can be encapsulated in PW
over a more modern infrastructure but these have little to do with the
motivation for MS-PW.

It has been said that GbE is the new T1.  It is three orders of
magnitude faster and is what the mid-sized to large enterprise market
today is looking to buy from their carriers.  Initially this was
handled within a metro as native L2 Ethernet because it was dirt cheap
due to commodity silicon and commodity switches suitable for the
enterprise market but beefed up a little for carrier.  The inter-metro
was handled using PW across the metros.

This all worked fine until the mesh of inter-metro connectivity
started to get too dense.  With thousands of metros, the aggregation
routers would need tens or hundreds of thousands of T-LDP sessions if
no aggregation at all was done.  Aggregation in the forwarding plane
was accomplished by putting all PW to the same destination within one
LDP LSP which gives merge capability, and also putting these inside
RSVP-TE LSP within the core to get TE and FRR and further data plane
aggregation throuhg LSP hierarchy.

That did not solve the control plane aggregation issue.  MS-PW solves
that issue by allowing a single T-LDP session to advertise multiple
FEC for multiple PW that traverse the same aggregation point.  At an
S-PE a label swap is done on the PW label avoiding any problems with
overlapping label spaces that might otherwise occur.

That an S-PE could sit at a provider boundary is more of a happy
coincidence than a motivation of MS-PW.

As to OAM, the PW OAM would best be kept end-to-end wrt the PW.  The
set of PW between any given T-PE and S-PE or S-PE and S-PE are likely
aggregated into a common LSP (or one per service class at most) and
these LSP are monitored separately.

Your ramblings about MEG ID and VLAN tags doesn't appear to be related
to the prior messages on this thread.

OAM in this situation seems straight-forward.  The LSP are server
layers for the PW.  The LSP are not end to end.  The MW-PW is end to
end segmented and therefore the S-PE may serve as MIP.  This works
very nicely for BFD and LSP Ping and VCCV with the IP address space so
the only extensions for MPLS-TP would be to accommodate the non-IP,
non-routable address spaces and identifying a back channel for the PW
OAM, and be sure to cover the MIP case at the S-PE.

Curtis

In message <[email-masked]>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 16:21:51 +0200

Curtis,

I am very much aware of how we build a scalable dataplane, and this is (as
you describe) by use of multiplexing transport service layer signals (i.e.
service-lsp, PWs, HVPLS instances) into transport path layer signals at a
domain boundary and to demux those again at the next domain boundary and
then switch and multiplex those again into the next domain's transport path
layer signals.

This dataplane scalability architecture applies to all types of client
signals; i.e. E1/T1, p2p Ethernet, mp Ethernet, ATM, FR, MPLS LDP LSP, MPLS
RSVP-TE LSP, MPLS PW, etc. For all those clients MPLS-TP networks need to
support multi-segment transport service layer connections.

Those multi-segment transport service layer connections support a
single-segment of client layer connections. If there is a T-LDP scaling
problem in MPLS-TP networks with only SS-PWs carried inside of
MS-service-LSPs, then I expect that there would also be a scaling problem in
MPLS-TP networks which carry a large number of MPLS LDP LSPs. I.e. those LDP
LSPs are only visible in the MPLS-TP edge ports, i.e. the same location as
where the MPLS-TP T-LDP SS-PWs would be visible. 

As an example, consider a multi-domain MPLS-TP network which supports
A) 1 million Ethernet SS-PWs carried in 1 million MS-service-LSPs, or
B) 1 million MPLS LDP LSPs carried in 1 million MS-service-LSPs.

My question is why would there be a PW control plane scalability problem in
case A and no LDP LSP control plane scalability problem in case B? In both
cases, the same number of client (i.e. SS-PW, LDP LSP) labels have to be
agreed between the edges of the MPLS-TP network. 

Or would there be a control plane scalability problem in both cases? 
Would MPLS-TP networks have to support multi-segment MPLS LDP LSPs, in
addition to multi-segment Ethernet PWs...

Or should we use the service-LSP's control plane to deliver the (SS-PW, LDP
LSP) labels to the edge nodes in the MPLS-TP network?

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 11 augustus 2010 16:49
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

Maarten,

You've provided interesting examples and reasoning but they may not match
the scaling problem and requirements that have motivated going from SS-PW to
MS-PW and the further mapping to scalable MPLS-TP deployment in that
environment.

E1 and T1 is legacy and its nice that it can be encapsulated in PW over a
more modern infrastructure but these have little to do with the motivation
for MS-PW.

It has been said that GbE is the new T1.  It is three orders of magnitude
faster and is what the mid-sized to large enterprise market today is looking
to buy from their carriers.  Initially this was handled within a metro as
native L2 Ethernet because it was dirt cheap due to commodity silicon and
commodity switches suitable for the enterprise market but beefed up a little
for carrier.  The inter-metro was handled using PW across the metros.

This all worked fine until the mesh of inter-metro connectivity started to
get too dense.  With thousands of metros, the aggregation routers would need
tens or hundreds of thousands of T-LDP sessions if no aggregation at all was
done.  Aggregation in the forwarding plane was accomplished by putting all
PW to the same destination within one LDP LSP which gives merge capability,
and also putting these inside RSVP-TE LSP within the core to get TE and FRR
and further data plane aggregation throuhg LSP hierarchy.

That did not solve the control plane aggregation issue.  MS-PW solves that
issue by allowing a single T-LDP session to advertise multiple FEC for
multiple PW that traverse the same aggregation point.  At an S-PE a label
swap is done on the PW label avoiding any problems with overlapping label
spaces that might otherwise occur.

That an S-PE could sit at a provider boundary is more of a happy coincidence
than a motivation of MS-PW.

As to OAM, the PW OAM would best be kept end-to-end wrt the PW.  The set of
PW between any given T-PE and S-PE or S-PE and S-PE are likely aggregated
into a common LSP (or one per service class at most) and these LSP are
monitored separately.

Your ramblings about MEG ID and VLAN tags doesn't appear to be related to
the prior messages on this thread.

OAM in this situation seems straight-forward.  The LSP are server layers for
the PW.  The LSP are not end to end.  The MW-PW is end to end segmented and
therefore the S-PE may serve as MIP.  This works very nicely for BFD and LSP
Ping and VCCV with the IP address space so the only extensions for MPLS-TP
would be to accommodate the non-IP, non-routable address spaces and
identifying a back channel for the PW OAM, and be sure to cover the MIP case
at the S-PE.

Curtis

Maarten Vissers writes:
>  
> Curtis, Stewart,
>  
> In an MS-PW the endpoints in the T-PE have to exchange information 
> with respect to e.g. the type of client and its encapsulation format 
> that the MS-PW will carry and configuration of MPLS-TP PW OAM 
> functions, e.g. MEG ID and if pro-active packet loss measurement is 
> supported. This information is important only for the endpoints and 
> intermediate S-PEs should not be bothered by it. Furthermore, if an
Ethernet PW carries a bundle of e.g.
> C-Tagged VLANs with different VIDs on the UNIs the endpoints have to 
> agree on the C-VID values that are used between the MS-PW endpoints 
> and how these relate onto the C-VID values on these UNIs.
>  
> mapping information and OAM config information, what problem is 
> introduced by requiring that this set of information includes agreeing 
> on a SS-PW label value?
>  
> Isn't the PW label value a representation of the type of client and 
> its encapsulation format, i.e. information that must be exchanged 
> between the two endpoints either way?
>  
> 4xE1). To support this, 4 TDM PWs are mapped into a (bundled service) 
> LSP in the T-PE nodes. The LSP is a multi-segment LSP and the four PWs are
SS-PWs.
> Both LSP endpoints need to agree on the PW label values for these four 
> TDM PWs, but those PWs do not need any MPLS-TP PW OAM; the bundled 
> service is monitored using LSP OAM. GMPLS should be able to take care 
> of the set up of this LSP and could also be used for the configuration 
> of the two endpoints, including the four SS-PW labels.
>  
> For the case of a service-LSP, the client mapping and endpoint 
> configuration information will be carried via GMPLS (is this 
> correct?); e.g. transport of
> 4 MPLS LSPs via one service-LSP will require to agree on the values of 
> the 4 LSP labels between the endpoints of the MPLS-TP network (i.e. 
> between MPLS-TP T-PE nodes supporting MPLS LSP services).
> If we use a service-LSP with a single SS-PW inside it, we could also 
> use GMPLS to carry the client mapping and endpoint configuration. The 
> SS-PW does not need any PW OAM; the service is monitored using the
service-LSP OAM.
>  
> If the client mapping and endpoint configuration information 
> (including MPLS LSP label value assignments) associated with a 
> service-LSP will not be carried via GMPLS, but instead via the MPLS 
> control plane, then we could get a large set of MPLS control plane 
> edge-to-edge relationships (assume that many MPLS LSPs are transported 
> via a large multi-domain MPLS-TP network), similar as we are 
> discussing for T-LDP controlling SS-PWs carried inside a similar
service-LSP in a large network.
> carried inside a service-LSP between MPLS-TP T-PE nodes, then I expect 
> a similar scaling problem for MPLS control plane case when we would 
> carry one or more MPLS LSPs inside a service-LSP between MPLS-TP T-PE
nodes.
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Curtis Villamizar
> In message <[email-masked]> Stewart Bryant writes:
> >  
> > >> 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) 
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?
> > >
> > > Yes.
> > >
> > > 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: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 18 Aug 2010 15:42:10 +0100

Maarten,

> agreed between the edges of the MPLS-TP network. 

The scaling issue is not with the number of labels but with the number of control "sessions" between different devices.

With LDP LSPs a router need to maintain an LDP control session with each of it's direct neighbours which would typically be a small number.

With SS-PWs a router needs to maintain a T-LDP control session with every other PE involved in one of its PWs. Depending on the level of meshing this could be a much larger number than the router needs to maintain for LDP LSPs (e.g. could require a full mesh of control connections between all PEs).

HTH
Ben

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Aug 2010 16:53:58 +0200

Ben,

For the case LDP LSPs are transported over a MPLS-TP network, then the LDP
Routers you refer to are located at the MPLS-TP T-PE locations and not
inside the MPLS-TP network. For this case those LDP LSP Routers would also
need to maintain a LDP control session with every other MPLS-TP T-PE
involved in one of its LDP LSPs. 

I.e. I am comparing the case in which MPLS LDP LSPs are a client of MPLS-TP.
For such case would there be a similar scalability problem?

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: woensdag 18 augustus 2010 16:42
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] SS-PW over inter-provider LSP

Maarten,

On 18 Aug 2010, at 15:21, Maarten Vissers wrote:
> single-segment of client layer connections. If there is a T-LDP 
> scaling problem in MPLS-TP networks with only SS-PWs carried inside of 
> MS-service-LSPs, then I expect that there would also be a scaling 
> problem in MPLS-TP networks which carry a large number of MPLS LDP 
> LSPs. I.e. those LDP LSPs are only visible in the MPLS-TP edge ports, 
> i.e. the same location as where the MPLS-TP T-LDP SS-PWs would be visible.
> 
> My question is why would there be a PW control plane scalability 
> problem in case A and no LDP LSP control plane scalability problem in 
> case B? In both cases, the same number of client (i.e. SS-PW, LDP LSP) 
> labels have to be agreed between the edges of the MPLS-TP network.

The scaling issue is not with the number of labels but with the number of
control "sessions" between different devices.

With LDP LSPs a router need to maintain an LDP control session with each of
it's direct neighbours which would typically be a small number.

With SS-PWs a router needs to maintain a T-LDP control session with every
other PE involved in one of its PWs. Depending on the level of meshing this
could be a much larger number than the router needs to maintain for LDP LSPs
(e.g. could require a full mesh of control connections between all PEs).

HTH
Ben

---

From: <[email-masked]>
Date: Wed, 18 Aug 2010 16:58:15 +0200

Hi all,

Agreed with Ben 

In the case the real issue to be solved is not the T-LDP scaling concern but rather the IP visibility between different areas (AS or IGP areas),
MS-PW stitching as described in "segmented PW" draft could offer an "MPLS-TP" layer, a transport layer service (each PW segment supported itself if we want over MPLS-TP :) ).
Then the VCCV/G-Ach would be used to carry the T-LDP for the inter-area dynamically service PW setup.
In that scenario PW service/MS-PW transport/MPLS LSP, we meet both requirements: IP transparency and dynamic PW service setup.

Regards,
Fred  

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Niven-Jenkins
Envoyé : mercredi 18 août 2010 16:42
À : Maarten Vissers
Cc : [email-masked]
Objet : Re: [mpls-tp] SS-PW over inter-provider LSP

Maarten,

HTH
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 18 Aug 2010 16:18:25 +0100

Maarten,

> For such case would there be a similar scalability problem?

I don't think so. The requirement for additional scale comes from the difference that with LDP your neighbour is typically directly connected (i.e. 1 hop away at the MPLS layer) whereas for T-LDP the neighbour is often multiple hops (at the MPLS layer) away.

Therefore the number of possible neighbours that are 1-hop from a given router is less than the total number of possible neighbours in the network. I know of networks where the difference between LDP neighbours and T-LDP neighbours is close to two orders of magnitude.

I don't see how MPLS-TP changes this assuming a client/server relationship between MPLS & MPLS-TP layer networks - i.e just because an MPLS-TP connection is being used to carry higher layer MPLS traffic doesn't mean that the MPLS network will contain more meshing between its routers than if it were running over a different server layer technology, SDH for example.

Ben

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Aug 2010 19:29:58 -0400

In message <[email-masked]>
> support multi-segment transport service layer connections.

None of which have much multidonaim deployment, but we'll ignore that
for now...

> where the MPLS-TP T-LDP SS-PWs would be visible. 

LDP scaling and PW T-LDP scaling are two completely different things.
LDP normally only establishes hop by hop adjacencies, with the hops
extended a bit when there is an underlying RSVP-TE layer.  There is no
constraint to have an LDP adjacency edge-to-edge.  In SS-PW the T-LDP
adjacency is by definition edge-to-edge.

> B) 1 million MPLS LDP LSPs carried in 1 million MS-service-LSPs.

Is this using a 21 or 22 bit label space?  1M is 20 bits.  :-)

OK so in this example the data plane doesn't scale either.  We can
ignore that for the moment.  Divide the load at any site among two
nodes and only about 19-ish bits are needed.

If this is a link between domains, the answer is easy.  All PW go
through as few as one LSP and there is a S-PE on either side.  The
size of physical links may force link bundling and more than one LSP
or alternately, a non-TP MPLS LSP can be used over a fat LAG.

Note: even 1M times 10Mb/s is a fairly big number.  10Tb/s is more
than one 100GbE can handle.  1M T1s or E1s would fit easily in one
100GbE, but T1 and E1 are not of much interest anymore.

If there is an edge node with 1M PW then there is a difference
scalability problem but that too is solvable.

Consider case C.

If there were 1M PW going to 100K other places, there would be only a
need for 100K LSP if they were edge-to-edge LSP.  This would be the
case with an average of 10 interfaces running PW per node.  If there
were 1K major metro areas, then the edge can connect via an LSP to the
nearest metro (where on average 100 nodes attach), another inter-metro
LSP, and a third LSP from metro to far edge.  At most an LSR then has
1,100 LSP.  This is practical in either LDP or RSVP-TE.  With MS-PW
this is easy to do and similar scalability is accomplished in the
T-LDP.  The edge device with 1M PW has only one T-LDP session with
lots of PW FEC advertised.

Add some nodes at the metro aggregation for redundancy and the exmaple
becomes more realistic but scaling isn't affected much.

> agreed between the edges of the MPLS-TP network. 

The answer is both case A and case B don't scale well.  Case C scales
much better but it uses MS-PW.

> addition to multi-segment Ethernet PWs...

In the case C example, there is no edge-to-edge LSP at all.

> LSP) labels to the edge nodes in the MPLS-TP network?

No wonder you LAN and transport guys can't get anything to scale.  :-)

Of course if you want to connect a billion computers instead of a
million, you'll need IP and route aggregation (not 1 billion host
routes or MAC addresses).  Similarly, subdividing a network to improve
scalability makes the 20 bit label space not a problem either.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 19 Aug 2010 09:57:43 +0200

Curtis,

LDP scaling and PW T-LDP scaling are two completely different things.
LDP normally only establishes hop by hop adjacencies, with the hops extended
a bit when there is an underlying RSVP-TE layer.  There is no constraint to
have an LDP adjacency edge-to-edge.  In SS-PW the T-LDP adjacency is by
definition edge-to-edge.

[maarten] From the viewpoint of a RSVP-TE layer its client LDP is
edge-to-edge. 
The edges are however not too far apart as you indicate by "the hops
extended a bit". 
When using a multi-domain MPLS-TP network these edges would be much further
apart; i.e. kind of "the hops extended a lot". 

[maarten] I assume that each transport-LSP would only have to carry some
hundreds to thousand of those service-LSPs. So each transport-LSP needs to
use about 8 to 12 bits of the 20-bit service-LSP label space. :-) 

[maarten] Please be aware that SDH networks support millions of E1/T1s and
have only 6-bit/5-bit labels to identify their "service-LSPs" (i.e.
VC12/VC11) within their "transport-LSPs" (i.e. VC4/VC3).

OK so in this example the data plane doesn't scale either.  We can ignore
that for the moment.  Divide the load at any site among two nodes and only
about 19-ish bits are needed.

[maarten] I would assume that there are e.g. 1000 nodes, each node
interconnected to 999 other nodes. And each of those 1000 nodes is connected
with the MPLS-TP network via M (M>=1) physical links. I.e. just the normal
transport network architecture; scales very well. If each customer edge node
is connected via 10 Mb/s with each other one, then each node has about 1000
x 10M = 10 Gb/s of bandwidth, which is not much and would fit into one 10GE
interface. 1000 x 100 Mbit/s would fit into ten 10GE signals.

[maarten] The MPLS-TP network could have 50 metro domains, each with 20 edge
nodes and at least N (N>=2) metro-core nodes connecting the metro with the
core. These 20 metro edge nodes each have N (unprotected) or 2N (protected)
transport-LSPs to connect with the N metro core nodes. Each metro-core node
has 20N or 40N metro transport-LSPs and e.g. 49N or 98N core transport-LSPs;
for N=2 such node will have 276 transport-LSPs terminating. Each metro-core
node would now support about 20k service-LSPs (which go edge-to-ege in the
MPLS-TP network); a very moderate number...

[maarten] The MPLS-TP network with 1 million edge-to-edge service-LSPs will
have no problem to support and set up those service-LSPs and transport-LSPs.
The service/transport LSP control plane (i.e. GMPLS) will be able to support
these numbers.

[maarten] The issue is that the e.g. Ethernet SS-PWs carried inside the
service-LSPs can not be set up via T-LDP as T-LDP would have too many
neighbours. Two solutions I can see to turn this around:
1) have the service-LSP control plane control also the SS-PW label; how much
additional work will this be for the service-LSP control plane... not much I
assume.
2) make use of the fact that in MPLS-TP the control plane is dealt with
out-of-band (OOB). This implies that it is possible to install T-LDP
signalling points at intermediate points in the MPLS-TP network, without
having at those points any PW dataplane processing; i.e. no need for MS-PWs
in MPLS-TP.

Regards,
Maarten
PS. Could we use a similar approach for the case a MPLS-TP netowrk has to
support 1 million MPLS LDP LSPs? I.e. could those LDP LSPs be carried by
MPLS-TP service-LSPs and could the MPLS LDP neighbour issue be resolved by
deploying LDP LSP signalling points in the MPLS-TP network?

If this is a link between domains, the answer is easy.  All PW go through as
few as one LSP and there is a S-PE on either side.  The size of physical
links may force link bundling and more than one LSP or alternately, a non-TP
MPLS LSP can be used over a fat LAG.

Note: even 1M times 10Mb/s is a fairly big number.  10Tb/s is more than one
100GbE can handle.  1M T1s or E1s would fit easily in one 100GbE, but T1 and
E1 are not of much interest anymore.

If there is an edge node with 1M PW then there is a difference scalability
problem but that too is solvable.

Consider case C.

If there were 1M PW going to 100K other places, there would be only a need
for 100K LSP if they were edge-to-edge LSP.  This would be the case with an
average of 10 interfaces running PW per node.  If there were 1K major metro
areas, then the edge can connect via an LSP to the nearest metro (where on
average 100 nodes attach), another inter-metro LSP, and a third LSP from
metro to far edge.  At most an LSR then has 1,100 LSP.  This is practical in
either LDP or RSVP-TE.  With MS-PW this is easy to do and similar
scalability is accomplished in the T-LDP.  The edge device with 1M PW has
only one T-LDP session with lots of PW FEC advertised.

> labels have to be agreed between the edges of the MPLS-TP network.

The answer is both case A and case B don't scale well.  Case C scales much
better but it uses MS-PW.

Of course if you want to connect a billion computers instead of a million,
you'll need IP and route aggregation (not 1 billion host routes or MAC
addresses).  Similarly, subdividing a network to improve scalability makes
the 20 bit label space not a problem either.

Curtis