Subject: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP) over MPLS(-TP)

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Feb 2009 01:06:56 +0000

Colleagues,

During private discussion with some folks it seems clear that the
requirement for MPLS(-TP) over MPLS(-TP) is not well articulated in the
requirements draft.

Currently we have:
   20  A generic and extensible solution MUST be provided to support the
       transport of one or more client layer networks (e.g.  MPLS-TP,
       Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.

   21  A solution MUST be provided to support the transport of MPLS-TP
       transport paths over one or more server layer networks (such as
       MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).  Requirements for
       bandwidth management within a server layer network are outside
       the scope of this document.

   22  In an environment where an MPLS-TP layer network is supporting a
       client network, and the MPLS-TP layer network is supported by a
       server layer network then operation of the MPLS-TP layer network
       MUST be possible without any dependencies on the server or client
       network.

I always thought these were sufficient and they cover many more cases than
just MPLS(-TP) over MPLS(-TP) but from those discussions I have had recently
it seems to me that it might worthwhile to explicitly call out the MPLS(-TP)
over MPLS(-TP) case.

As such I suggest adding the following requirement after requirement 22

23  A solution MUST be provided to support the transport of a client MPLS or
MPLS-TP layer network over a server MPLS or MPLS-TP layer network.

    A  The level of co-ordination required between the client and server
MPLS(-TP) layer networks MUST be minimised (preferably no co-ordination will
be required).

    B  The MPLS(-TP) server layer network MUST be capable of transporting
the complete set of packets generated by the client MPLS(-TP) layer network,
which may contain packets that are not MPLS packets (e.g. IP or CNLS packets
used by the control/management plane of the client MPLS(-TP) layer network)

Unless anyone objects I will add the above proposed requirement as part of
updating the requirements draft to version -05 following WG LC.

Ben

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 25 Feb 2009 19:29:31 -0800

Hi Ben,

I think your proposed addition is very useful and I support it.

rahul

On Thu, 26 Feb 2009, Ben Niven-Jenkins wrote:

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 26 Feb 2009 07:23:29 +0100

I support the additional text

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Ben Niven-Jenkins
Sent: Thursday, February 26, 2009 03:07
To: [email-masked]
Subject: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Colleagues,

Currently we have:

I always thought these were sufficient and they cover many more cases
than
just MPLS(-TP) over MPLS(-TP) but from those discussions I have had
recently
it seems to me that it might worthwhile to explicitly call out the
MPLS(-TP)
over MPLS(-TP) case.

23  A solution MUST be provided to support the transport of a client
MPLS or
MPLS-TP layer network over a server MPLS or MPLS-TP layer network.

    A  The level of co-ordination required between the client and server
MPLS(-TP) layer networks MUST be minimised (preferably no co-ordination
will
be required).

    B  The MPLS(-TP) server layer network MUST be capable of
transporting
the complete set of packets generated by the client MPLS(-TP) layer
network,
which may contain packets that are not MPLS packets (e.g. IP or CNLS
packets
used by the control/management plane of the client MPLS(-TP) layer
network)

Unless anyone objects I will add the above proposed requirement as part
of
updating the requirements draft to version -05 following WG LC.

Ben

---

From: <[email-masked]>
Date: Thu, 26 Feb 2009 08:06:55 -0000

Thanks Ben,  Looks generally OK to me.  But I think we need to exercise
a little care with all 4 C/S combinations here and be very specific with
what we mean by 'MPLS'.

And what I mean by this at a high-level is that we must be designing
MPLS-TP with a transport network role in mind (eg C/S transparency) and
it must therefore be fixing something that is not quite right in
MPLS...it has to, else we have no need to work on it.

However, there is more to it than this high-level observation.

We will only be defining a single type of MPLS-TP.  But MPLS is not
singular by definition...we allow many ways to allocate/distribute
labels.  And those labels have different semantics depending on:
(i) what 'signalling' protocol issued them (I say 'signalling' because
whilst RSVP-TE and targetted LDP can be classified as signalling one
cannot call vanilla LDP signalling in a co-ps context, and I'd hestitate
to call labels issued by MP-BGP4 as signalling)
(ii) what application context they apply to.

In the past folks should have noticed me refer to the fact that (a) MPLS
is not singular and (b) MPLS does note have consistent Characteristic
Information....well the above is what I mean by this.

So when we say 'MPLS' we should also say what type of MPLS.  So whilst
there is no problem with MPLSoverMPLS-TP and MPLS-TPoverMPLS-TP
(assuming we get the MPLS-TP design right) it is not at all clear to me
what MPLS-TPoverMPLS and MPLSoverMPLS really means.

Let me give an example of what I mean here:

MPLS-TP is supposed to be being designed to provide a transparent
transport role for its clients.  But MPLS_LDP does not provide a
transparent transport role whilst MPLS_RSVP-TE can do so.

So whilst MPLS-TPoverMPLS_RSVP-TE and MPLS(any)overMPLS_RSVP-TE should
be OK I could not say the same for MPLS-TPoverMPLS_LDP or indeed
MPLS(any)overMPLS_LDP.

And the key observation from the requirements of C/S transprency are
that the server must not allow the traffic behaviour of client X to
impact the performance experienced by client Y.

I hope everyone can understand what I mean by this.  

regards. Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: 26 February 2009 01:07
> To: [email-masked]
> Subject: [mpls-tp] Clarifying MPLS-TP requirements for 
> MPLS(-TP) overMPLS(-TP)
> 
> Colleagues,
>

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 26 Feb 2009 09:22:29 +0100

Ben,

I was fine with the first ones, I am also mostly fine with the
additional reqs.
Two small comments still:
- If you remove "(-TP)" from the text, which apparently is a possibility
knowing that it is in parenthesis, you are putting requirements on MPLS
which is a bit strange, isn't it?

- Second, if the MPLS(-TP) client layer described in 23.B is capable of 
generating unlabeled packets then this req constrains the MPLS(-TP) 
server layer network to be able to handle these raw packets at least
at the edge. Do we want that?

thanks,
-m

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Feb 2009 12:04:28 +0000

Neil,

MPLS-TP is a subset of the MPLS toolkit where we adding to the MPLS toolkit
those functions necessary to realise MPLS-TP that aren't already in the MPLS
toolkit.

Use of MPLS(-TP) is purely for brevity as otherwise we will end up with
pages of text on this in the requirements.

However, I agree with you not all combinations make sense for all
applications. This is no different with today's networks and it is the
responsibility of the operators to ensure they are buying server layer
services that meet the requirements of their client layer networks, e.g. If
I am buying an "Ethernet circuit" today I want to know if that is provided
over a shared LAN infrastructure or I am buying a reserved bandwidth VLAN so
I can ensure it will meet the requirements of the service/network I wish to
run over it. 

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Feb 2009 12:21:13 +0000

> which is a bit strange, isn't it?

Not really, MPLS-TP is a subset of MPLS where we are expanding the MPLS
toolkit to meet the requirements of MPLS-TP. Furthermore it is perfectly
possible that parts of an MPLS-TP network may be supported by an MPLS
network using for example draft-ietf-mpls-transport.

> at the edge. Do we want that?

Yes, but the level of "handling" may be minimal/0. Look at a non-packet
transport network - it takes a stream of client layer network packets and
encapsulates and transports them, it doesn't "handle" the packets as such.
We need something similar for MPLS(-TP). E.g. If one is doing MPLS over
MPLS-TP, in order for the two client MPLS LSRs to communicate with one
another they use both labelled and unlabelled packets, when such
communication is over a transport network the transport network must be
capable of taking that stream of labelled & unlabelled packets from LSR A
and transporting them transparently to LSR B.

Traditionally in packet/MPLS networks such a scenario (e.g. CsC) has been
handled by requiring some level of co-ordination between the the client and
server layer networks (e.g. Running a (client)CE-(server)PE protocol where
the messages are mapped into a (server)PE-(server)PE protocol and those
messages are finally mapped into a (server)PE-(client)CE protocol. The
necessary communication is therefore transferred from CE-CE but in a
non-transparent manner. That is not acceptable in many transport scenarios
as it relies on a level of co-ordination (even if through CE-PE protocol)
that is not acceptable.

The new requirement is not saying anything more than that which was implicit
in the pre-existing requirements but hopefully makes things a bit clearer as
when MPLS(-TP) over MPLS(-TP) has been discussed there appears to have been
a level of confusion as to what it actually means, i.e. Is it just
transporting labelled MPLS packets or the full set of packets required for
two LSRs to form a routing adjacency etc.
   
HTH 
Ben

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 26 Feb 2009 09:19:49 -0500

Ben, perhaps the concern raised by Neil could be addressed by adding the
following sentence to the end of requirement 22:
"However the server layer MUST guarantee that the traffic loading
imposed by other clients does not cause the transport service provided
to the MPLS-TP layer to fall bellow the agreed level."

Also, how are the three other major issues raised by Neil in a mail sent
14/02/2009 at 9:41AM been addressed - body copied below:

"1	 Transparent client/server relationship:

If MPLS-TP is to succeed in a transport role it will essential that it
can provide a transparent client/server relationship between different
instances of MPLS-TP layer networks owned by the same or different
parties, ie MPLS-TPoverMPLS-TP.  One way this could be achieved is by
the use of special label for this purpose only.  However, if we want a
more general client/server solution (which I believe is the case) then
we should consider how to implement a generic adaptation function that
provides a client PID capability.

Aside=> Current co-cs generation transport networks (based on PDH, SDH
and OTN) use GFP as the common/generic adaptation function for their
clients.  GFP has a PID function (in the UPI field) that already
identifies important SAN clients, and it also has values for Ethernet,
IP and MPLS clients.  Since the ease of migration/interworking of
current and next generation transport networks is important for network
operators, then the use of GFP in MPLS-TP should be given serious
consideration.

2	MPLS-TP OAM:

MPLS-TP OAM functions must be client layer network agnostic and appear
as identical as possible to MPLS-TP traffic units at the MPLS-TP layer
network under consideration.  From technical considerations a TTL field
is not required in any co-ps/co-cs mode layer network (the CP/MP can
ensure there are no loops before establishing a LSP) and thus the
existing MPLS TTL field could be used for other important functions such
as an OAM indicate function (this would only require 1 bit, noting that
the TTL field consumes 25% of a scarce resource in the MPLS-TP header).
However, if this is deemed not possible (for whatever reason, but which
clearly cannot be technical) then some other way must be found to ensure
this.  

3	PWs and MPLS-TP:

We must be very clear that PWs are a consequence of the way MPLS was
originally specified;  in particular the different way in which IP and
all other clients were handled, and the consequences of LDP merging and
ECMP load spreading.  For MPLS-TP to take on a transport role however,
its design must be changed such that it treats all clients equally (ie
point 1 above) and merging behaviour is removed.

We should also note that when PWs were only a 1-hop entity in MPLS they
could be considered as an adaptation-like function.  However, when PWs
became multi-segment constructs (ie MS-PWs) then they underwent a very
significant change in behaviour and became a co-ps layer network in
their own right above MPLS.

Now given MPLS-TP is supposed to be a transport network, then it would
make no sense whatsoever for it to create a further co-ps mode (PW)
layer network above it.  Indeed, this would be completely at odds with
the requirement for a generic transparent client/server relationship
noted in 1 above.

>From purely technical considerations it is therefore quite clear that
MPLS-TP has no need to have PWs.  However, they could be kept (at least
in name) providing they reverted back to their original 1-hop
adaptation-like functionality and did not generate a co-ps layer network
above MPLS-TP.

regards, Neil"
 
Perhaps the first could be addressed by adding the following text to the
end of requirement 23.
"It MUST be possible to isolate the control and management planes of the
MPLS-TP layer network from the control and management planes of the
client and server layer networks."

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ben Niven-Jenkins
Sent: Thursday, February 26, 2009 7:04 AM
To: Harrison,N,Neil,CXM R; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Neil,

MPLS-TP is a subset of the MPLS toolkit where we adding to the MPLS
toolkit those functions necessary to realise MPLS-TP that aren't already
in the MPLS toolkit.

However, I agree with you not all combinations make sense for all
applications. This is no different with today's networks and it is the
responsibility of the operators to ensure they are buying server layer
services that meet the requirements of their client layer networks, e.g.
If I am buying an "Ethernet circuit" today I want to know if that is
provided over a shared LAN infrastructure or I am buying a reserved
bandwidth VLAN so I can ensure it will meet the requirements of the
service/network I wish to run over it. 

Ben

On 26/02/2009 08:06, "Harrison,N,Neil,CXM R" <[email-masked]>
wrote:

> Thanks Ben,  Looks generally OK to me.  But I think we need to 
> exercise a little care with all 4 C/S combinations here and be very 
> specific with what we mean by 'MPLS'.
> 
> MPLS-TP with a transport network role in mind (eg C/S transparency) 
> and it must therefore be fixing something that is not quite right in 

> cannot call vanilla LDP signalling in a co-ps context, and I'd 
> hestitate to call labels issued by MP-BGP4 as signalling)
> In the past folks should have noticed me refer to the fact that (a) 
> MPLS is not singular and (b) MPLS does note have consistent 
> Characteristic Information....well the above is what I mean by this.
> 

> (assuming we get the MPLS-TP design right) it is not at all clear to 
> me what MPLS-TPoverMPLS and MPLSoverMPLS really means.
> 

>> requirement for MPLS(-TP) over MPLS(-TP) is not well articulated in 
>> the requirements draft.
>> 
>> Currently we have:
>>    22  In an environment where an MPLS-TP layer network is supporting

>> a

>> than just MPLS(-TP) over MPLS(-TP) but from those discussions I have 
>> had recently it seems to me that it might worthwhile to explicitly 
>> call out the MPLS(-TP) over MPLS(-TP) case.
>> 
>> MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer 
>> network.
>> 
>> MPLS(-TP) layer networks MUST be minimised (preferably no 
>> co-ordination will be required).
>> 
>> transporting the complete set of packets generated by the client 
>> MPLS(-TP) layer network, which may contain packets that are not MPLS 
>> packets (e.g. IP or CNLS packets used by the control/management plane

>> of the client MPLS(-TP) layer network)
>> 
>> 
>> Unless anyone objects I will add the above proposed requirement as 
>> part of updating the requirements draft to version -05 following WG 
>> LC.
>> 
>> Ben
>> 
>> 
>>

---

From: <[email-masked]>
Date: Thu, 26 Feb 2009 15:07:32 -0000

Thanks Ben,  yes I know this is a general observation and not specific
to MPLS (though MPLS has some unusal variations that are not found in
other technologies that can make it unsuitable for a transparent
transport role).  Indeed a request for server layer transparency should
be sufficient if this is applied recursively down the stack and everyone
is clear on what transparency actually means.

But please note I have to disagree with you that 'MPLS-TP is subset of
the MPLS toolkit'.  MPLS-TP will require new components that are not
found in MPLS (such as OOB CP/MP, GAL, proper PID function) and will
dispense with those that are a hindrance to a transparent transport role
(such as LDP/PHP merging, ECMP, inconsistent CI, and PWs...at least as
another co-ps layer network above it).  So it is not really a subset but
a new layer network technology that is trying to re-use as many
components from the MPLS parts-bin as possible, but it is also adding
new ones where they are needed (inc the GMPLS CP approach).

I am really hoping that the important issues that have been raised in
these technical discussions help us to make an excellent job of it.

regards, Neil  

> From: Niven-jenkins,B,Ben,DMF R 
> Sent: 26 February 2009 12:04
> Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for 
> MPLS(-TP) overMPLS(-TP)
> 
> Neil,
>

---

From: <[email-masked]>
Date: Thu, 26 Feb 2009 15:30:48 -0000

Hi Ben/Martin...some minor points here:
 
Ben wrote 26 February 2009 12:21
> toolkit to meet the requirements of MPLS-TP.
NH=> I think it is more accurate for us to state this as something like:
"MPLS-TP will provide a new layer network that has been designed by IETF
to provide a transparent transport role which reuses as many components
from MPLS and GMPLS as possible."

> Furthermore it 
> is perfectly
NH=> Is the title of this draft accurate?....are you meaning the draft
Stewart wrote that time expired or something else?

> encapsulates and transports them, it doesn't "handle" the 
NH=> You raise a crucial point here Ben....and this is exactly why the
word *transparency* has such a key meaning.  A transparent transport
network (like PDH, SDH, OTN today) has these properties:
-	treats all client symbols equally
-	preserves client symbol ordering
-	makes no attempt to infer meaning from the client symbols and
never modifies them
-	ensures that it is possible for the traffic behaviour of client
X not to impact the performance experienced by client Y

> and transporting them transparently to LSR B.
NH=> Exactly so....though it is perhaps more general to refer to client
layer symbols (which at the smallest level of information (symbol)
recursion are 'bits').  Of course the actual adaptation function between
the client and server has to know some things about the nature of the
client, but the server layer trail does not (it should be client
agnostic)...and note that this is where the defect detection/handling
server layer OAM should be injected/removed.
> as it relies on a level of co-ordination (even if through 
NH=> I think the easiest way to describe this important aspect is to say
that the client and server layer networks are functionally disjoint in
all 3 planes.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 26 Feb 2009 17:06:44 +0100

Neil,

> Of course the actual adaptation function between the client and server 
> has to know some things about the nature of the client, but the server
> layer trail does not (it should be client agnostic) 

and 

> -	makes no attempt to infer meaning from the client symbols 

include an inconsistency. The adaptation function interpretes e.g. the
priority and drop eligible information encoded in the client signal, and
maps this onto equivalent priority/drop eligible information used in the
server layer. 

In a true transparent client/server relationship it is possible that the
client changes its information encoding (e.g. reverts the priority encoding,
inverts the drop eligible encoding) without causing any impact on the
transport of this information by the server layer trail. I.e. as you
correctly note for PDH, SDH and OTN server layer trails (which have a single
priority level and drop eligible level).

For the case of carrying a client signal over a packet server layer trail,
such true transparency is not possible. The adaptation function interpretes
the encoded client priority/drop eligible information and maps this onto the
server priority/drop eligible information. If the client would revert the
priority encoding and invert the drop eligible encoding (in true
transparency this is possible), then all the client's high priority
frames/packets will be treated as best effort packets/frames in the server
layer trail; consequently delivery and timing are not guaranteed and SLA
will not be met. I.e. a packet server layer trail is not transparent to
packet client layer information.

There is only one solution to this problem, and that is to use only packet
server layer trails with one priority level (highest) and no drop eligible
allowance.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: donderdag 26 februari 2009 16:31
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

> Not really, MPLS-TP is a subset of MPLS where we are expanding the 
> MPLS toolkit to meet the requirements of MPLS-TP.
NH=> I think it is more accurate for us to state this as something like:
"MPLS-TP will provide a new layer network that has been designed by IETF to
provide a transparent transport role which reuses as many components from
MPLS and GMPLS as possible."

> Yes, but the level of "handling" may be minimal/0. Look at a 
> non-packet transport network - it takes a stream of client layer 
> network packets and encapsulates and transports them, it doesn't 
> "handle" the packets as such.
NH=> You raise a crucial point here Ben....and this is exactly why the word
*transparency* has such a key meaning.  A transparent transport network
(like PDH, SDH, OTN today) has these properties:
-	treats all client symbols equally
-	preserves client symbol ordering
-	makes no attempt to infer meaning from the client symbols and
never modifies them
-	ensures that it is possible for the traffic behaviour of client
X not to impact the performance experienced by client Y

> We need something similar for MPLS(-TP). E.g. If one is doing MPLS 
> over MPLS-TP, in order for the two client MPLS LSRs to communicate 
> with one another they use both labelled and unlabelled packets, when 
> such communication is over a transport network the transport network 
> must be capable of taking that stream of labelled & unlabelled packets 
> from LSR A and transporting them transparently to LSR B.
NH=> Exactly so....though it is perhaps more general to refer to client
layer symbols (which at the smallest level of information (symbol) recursion
are 'bits').  Of course the actual adaptation function between the client
and server has to know some things about the nature of the client, but the
server layer trail does not (it should be client agnostic)...and note that
this is where the defect detection/handling server layer OAM should be
injected/removed.
> handled by requiring some level of co-ordination between the the 
> client and server layer networks (e.g. Running a (client)CE-(server)PE 
> protocol where the messages are mapped into a (server)PE-(server)PE 
> protocol and those messages are finally mapped into a 
> (server)PE-(client)CE protocol. The necessary communication is 
> therefore transferred from CE-CE but in a non-transparent manner. That 
> is not acceptable in many transport scenarios as it relies on a level 
> of co-ordination (even if through CE-PE protocol) that is not 
> acceptable.
NH=> I think the easiest way to describe this important aspect is to say
that the client and server layer networks are functionally disjoint in all 3
planes.

regards, Neil
> 
> The new requirement is not saying anything more than that which was 
> implicit in the pre-existing requirements but hopefully makes things a 
> bit clearer as when MPLS(-TP) over MPLS(-TP) has been discussed there 
> appears to have been a level of confusion as to what it actually 
> means, i.e. Is it just transporting labelled MPLS packets or the full 
> set of packets required for two LSRs to form a routing adjacency etc.
>    
> HTH 
> Ben
>

---

From: <[email-masked]>
Date: Thu, 26 Feb 2009 18:33:48 -0000

Thanks Maarten.... who wrote 26 February 2009 16:07

> include an inconsistency.

Not for a transport network based on the co-cs mode it doesn't.  There
are no QoS classes in the co-cs mode, this is a forced behaviour of its
physics and its *a very, very good thing* from practical considerations
(I'll come back on this latter point shortly).....which it why it makes
an ideal transport network solution and has been enduringly successful
in this role.

We can do all manner of things to the co-ps mode that cannot be done to
the co-cs mode....ranging from having lots of QoS classes in a single
connection, to overbooking the server layer resources (to varying
degrees), and even violating the single source rule of a connection.
Each of these in an increasingly more silly thing to do architecturally
if your aim is to provide a simple transparent transport network.

However, I would not stop anyone from doing what you suggest....and that
why, when I am talking about issues like performance inheritance say, I
carefully separate the 2 requirements of:
-	MUST not violate the rules of a connection...a necessary
requirement, from
-	SHOULD not overbook its resources....a full-sufficiency
requirement

The former is quite destructive in its operational impact (on things
like efficient network design, OAM and resource management), whilst the
latter has shades of grey in its operational impact (a function of the
degree of overbooking and the temporal correlation of the very
top-of-stack end-system application information sources...that one
probably has no visibility of anyway in a lower level transport
network).

If resources never get overbooked there is no need to worry about
QoS...the co-cs never has and never will have QoS classes.  However, I
hasten to add this is NOT the same as survivability importance BUT that
should be a parameter of the (parent) connection and not its (child)
traffic units in co mode networks.

Aside=> One has to be very careful about this QoS vs survivability
importance difference ....even as a top-of-stack layer network that
directly interfaces with end-system message/file/stream applications.

*Any* application (of either message/file/stream) can take on *any*
survivability importance, whilst having fixed QoS (==delay essentially)
characteristics per application type.

Now, when we are providing a non-top-of-stack transport network service
(at increasingly higher bits rates with time) we really can't afford to
be worrying about the nature of **each specific** application above
us....in fact you usually can't even see them anyway!....one only sees
an aggregate, and often this is from another non-top-of-stack layer
network, eg MPLS-TPoverMPLS-TP would be like this, so is VC12overVC4 in
SDH, etc, etc.

So as a transport network, and especially as we move towards the duct,
we are usually dealing with a very large aggregate mix of
message/file/stream applications where the mix composition can vary
epoch by epoch and with completely unknown QoS/survivability
importance's for specific application instances.  It is therefore not
practically sensible (a massive understatement) for a non-top-of-stack
transport network to try and worry about this...it is far, far easier
(and cheaper) to treat the aggregate transparently at the bit
level....and which is what the co-cs mode does and why it's been
enduringly successful.

Just because the physics allows one to do something does not mean it is
practically sensible...one can often generate a huge amount of rather
unnecessary work/cost......and the above is just one example of this.

regards, Neil
<snipped to end>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 27 Feb 2009 14:03:24 +0000

Neil,

> new ones where they are needed (inc the GMPLS CP approach).

AFAIK any new components will apply & be usable in MPLS as well as MPLS-TP,
therefore any new components will form part of the MPLS toolkit and MPLS-TP
will be a subset of that new & expanded MPLS toolkit.

The parallel to PBB & PBB-TE springs to mind - both share a common "Ethernet
tookit" but PBB-TE only uses a restricted subset of functionality.

We agree that MPLS & MPLS-TP will form different layer network instances.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 27 Feb 2009 14:06:48 +0000

Neil,

> Stewart wrote that time expired or something else?

Yes I was referring to the draft Stewart edited, I may have got the draft
name wrong.

> that the client and server layer networks are functionally disjoint in

Easiest is not always clearest. While you/I/others understand your short &
sweet sentence above I have found many others who do not fully grasp the
true meaning conveyed so I have found illustration by example useful to
tease out that understanding.

Ben