Subject: Re: [PWE3] GAL above and below the PW label

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sun, 3 Apr 2011 19:39:26 +0100

On 31 Mar 2011, at 12:27, Giles Heron wrote:

> On 31/03/2011 09:20, "Stewart Bryant" <[email-masked]> wrote:
> 
>> On 30/03/2011 14:55, Greg Mirsky wrote:
>>> Dear Sasha,
>>> I believe that there should not be MS-PW that crosses TP and non-TP
>>> domains. 
>> That diminishes the generality of the design, which would in my view be
>> a bad thing.
> 
> Agreed.  I'd expect the most common use case for TP is in the
> access/aggregation.  So you might have an MS-PW with 3 segments:
> 
> MPLS TP <-> IP/MPLS <-> MPLS-TP.

That was certainly the use case I was looking at using TP for when I wrote

http://tools.ietf.org/html/draft-jenkins-mpls-tp-bt-requirements-00

Ben

---

From: <[email-masked]>
Date: Mon, 4 Apr 2011 09:48:10 +0100

Hi Ben,

> Benjamin Niven-Jenkins wrote 03 April 2011 19:39
> 

To be clear Ben, I assume:

1	You are implying that there is a proper client/server relationship between each of the 3 MPLS server layer network partitions you identify above, where the PW layer network is transparently carried across each of the 3 independent server MPLS domains (which of course can belong to different operating parties).

Aside=> There is of course an even higher layer network X link connection carried transparently by the E2E PW layer network path connection.

2	There is no 'peering' between logically adjacent server layer MPLS layer networks.....noting that non-TOS layer networks never need to peer in any case.

Note that an immediate corollary of the above is that the routing instance of the PW layer network must be obviously disjoint from any of the 3 server MPLS layer networks.

Am I reading you correct here?

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Wed, 6 Apr 2011 23:31:00 +0100

> 1	You are implying that there is a proper client/server relationship between each of the 3 MPLS server layer network partitions you identify above, where the PW layer network is transparently carri…

Yes. Although the case I had in mind was MS-PW where there was a separate PW segment for each of the MPLS server layers, the fact that there would have been a 1:1 mapping between PW segments and MPLS server layers was incidental. The driver for MS-PW was because I needed the 'edge' PW segments to be statically configured to meet security requirements but I didn't want to place the same restrictions on the 'core' PW segment.

> 2	There is no 'peering' between logically adjacent server layer MPLS layer networks.....noting that non-TOS layer networks never need to peer in any case.

Correct.

Ben

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 07:00:48 +0100

Many thanks Ben for this important clarification.  I am glad we see essentially the same layered network architecture case/implications.  A couple of further remarks in-line only for completeness:

You wrote 06 April 2011 23:31:

> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] GAL above and below the PW label
> 
> 
> > 1	You are implying that there is a proper client/server relationship
> between each of the 3 MPLS server layer network partitions you identify
> above, where the PW layer network is transparently carried across each
> of the 3 independent server MPLS domains (which of course can belong to
> different operating parties).
> 
> Yes. Although the case I had in mind was MS-PW where there was a
> separate PW segment for each of the MPLS server layers, the fact that
> there would have been a 1:1 mapping between PW segments and MPLS server
> layers was incidental. 

NH=> This is the same as having some number N of consecutive link connections (that form a 'segment') of the MS PW LSP provided by the same serving MPLS layer network.  Of course, each individual PW link connection is an E2E MPLS LSP in its own right, they just happen to come from the same parent serving MPLS layer network.

> The driver for MS-PW was because I needed the
> 'edge' PW segments to be statically configured to meet security
> requirements but I didn't want to place the same restrictions on the
> 'core' PW segment.
> 
> > 2	There is no 'peering' between logically adjacent server layer MPLS
> layer networks.....noting that non-TOS layer networks never need to
> peer in any case.
> 
> Correct.

NH=> This is a vital point (though it is quite general to all client/server networking cases, not simply this case).  A couple of immediate (and perfectly correct/required) consequences of this are:

-	there is no need for E-NNIs between the serving MPLS layer networks....this is a logically obvious conclusion in any case simply from the observation that E-NNIs are technically unnecessary in any layer network technology that is not TOS (and thus external application interfacing).  This avoids much unnecessary complexity/costs.

-	the routing function of each and the serving MPLS layer networks must be independent of each other (stems directly from the above) and also independent of that of the E2E PW layer network that spans all the MPLS server layer networks.  Note - I've only picked on the routing function here to illustrate the fact that there cannot be a common instance of CP between all these layer networks, but this observation applies to all the functionality needed to specify/operate a layer network.

regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Apr 2011 23:20:44 -0400

In message <[email-masked]>
Benjamin Niven-Jenkins writes:
> > 1	You are implying that there is a proper client/server
> >   relationship between each of the 3 MPLS server layer network
> >   partitions you identify above, where the PW layer network is
> >   transparently carried across each of the 3 independent server MPLS
> >   domains (which of course can belong to different operating parties). 
>  
> there would have been a 1:1 mapping between PW segments and MPLS
> server layers was incidental. The driver for MS-PW was because I
> needed the 'edge' PW segments to be statically configured to meet
> security requirements but I didn't want to place the same restrictions
> on the 'core' PW segment.

This is off topic a bit but ...

Statically configuring each hop along a path does not in itself
support a security requirement.  Or maybe I should say, support a
security requirement that couldn't be supported by admission control.
For example, if an untrusted node such as a customer edge was doing
the signaling, the PE could reject anything that didn't have a loose
hop and the PE could dictate the rest of the path making it equivalent
to static.  Of course if the path is only the one hop from CE to PE,
then this is a moot point.

Also TP is not defined to be static.  MPLS can be static.  MPLS-TP can
use a control plane.  It may be that you are using MPLS-TP as static
in this usage and that is what you meant.

> > 2	There is no 'peering' between logically adjacent server layer
> >   MPLS layer networks.....noting that non-TOS layer networks never
> >   need to peer in any case. 
>  
> Correct.
>  
> Ben

Anyway, the point of the MPLS-TP <-> IP/MPLS <-> MPLS-TP example is
that the TP segments would see a GAL above a fat-pw where the fat-pw
would be needed in the MPLS segment only.  Doing a traceroute would
expose this use of GAL above another label at each TP hop.

If your point was that you envisioned using a MPLS-TP <-> IP/MPLS <->
MPLS-TP case for a different reason than the normally cited "because
it does OAM quite nicely", then point taken.

Regards,

Curtis