Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt

From: [email-masked]
Date: Sun, 19 Dec 2004 21:38:30 -0000

Hi Chris,
> 
> Hi-
> I think we are missing a specific USE CASE from section 5. 
> Consider the case where we have each PE pair run a client 
> control plane function. This control plane function drives 
> creation (and deletion) of corresponding PW segments between 
> each PE pair. Rather then terminate and process the PW 
> payload at each intermediate PE (between the source and 
> target U-PEs), we splice the preceding and succeeding PW 
> segments together ... so that the data plane at the intermediate
> PE(s) becomes a PW label swap operation.
> 
I believe you are, perhaps not intentionally, raising a very important
point here that has troubled me and many folks in BT for a long time.  I
can summarise this as follows:

When we have a topology of nodes and links in some layer network that we
wish to route a path across, there is an (unconscious?) assumption that
the link-connections (ie the 'things' that connect adjacent nodes
together) in THIS layer network really exist, ie they are ALREADY
provisioned in some manner between the nodes in THIS layer network.
However, these link-connections are provided by trails (ie end-end
paths) in some LOWER layer network (eg E1 PDH or VC12 SDH trails).  In
turn, the link connections of this lower layer network are provided by
trails in an EVEN LOWER lower layer layer network (eg SDH VC4).  This
behaviour (ie a client layer link-connection is provided by a server
layer trail) recurses until we hit the duct.

We can restate this in a different way (and I am tailoring this for the
PW case, but it can be generalised to any case of nested layer
networks):

-	For the client of the PW to work it requires a level N (MH PW)
LSP to be in place
-	For the level N (MH PW) LSP to work it requires a level N-1 LSP
to be in place (for EACH link/segment of the MH PW LSP as per the
recursion principle noted previously)
-	For the level N-1 LSP to work it requires a level N-2 LSP to be
in place (for EACH link/segment of the level N-1 LSP).....this can
continue for as many LSPs as there are nested, but let's stop the LSP
nesting here
-	For the level N-2 LSP to work it requires a (let's say) SDH VC4
path to be in place...again for EACH of its link connections, but let's
take this recursive/general requirement to be as-read from now on
-	For the SDH VC4 path to work its requires a STM MS/RS path to be
in place
-	For the STM MS/RS path to work it requires a fiber to be in
place
-	For the fiber to work it requires a duct to be in place.
-	For the duct to be in place it requires we get a back-hoe out
and dig some trenches!

In other words we cannot create 'topology on the fly'......a level or
pre-provisioning is a key requirement/assumption here.  But yet in MPLS
this assumes this is indeed possible (a similar issue occurs in GMPLS
when folks talk of 'TE links' and 'FAs').  Clearly this is a nonsense.
It's not a problem in MPLS as-is *provided* we only ever have 2 levels
of LSP AND  the top level LSP is not actually a true networked LSP but
merely a p2p 1-hop entity where the label proxies for a client
identifier function (which is precisely what we find with rfc2547 VPNs
and SH PWs).  However, for MH PWs each link-connection here (ie between
PW switching capable nodes) requires a 'regular' lower level LSP to be
in place before traffic can be sent, or indeed MH PW LSP routes to be
calculated with any valid sense...and this requires even lower level
trails to be in place, etc, etc, until we get to the duct.

I think you are assuming here Chris that the (PW) client control-plane
(or more accurately the client layer network across ALL planes) is
independent of the server MPLS (PW) control-plane (network)....and this
is a 'good thing' as one can can now functionally decouple the client
(whatever it is) and server (MPLS) layer networks.  Can't do this in
MPLS per se however......currently there is no good way of creating a
'functional breakwater' between 2 MPLS layer networks except by PWs and
some other technology.  As I noted, this is not a problem when we only
have a single layer network in MPLS and a higher level LSP is not really
a 'networked LSP' but a 1-hop client ID proxy.  MH PWs start to change
this picture however.....and so does client/server i/w between 2
operators A and B say, who both have MPLS networks and where operator A
wants to lease transport capacity off operator B but neither operator
wants to functionally peer with each other.

I think we have some interesting issues brewing here.

regards, Neil