Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 10:38:05 +0100

Neil,

MEF has an active E-NNI project. As there are many carriers in this world,
and as customers want connectivity irrespective of the specific carrier
present in a domain, E-NNIs are a mandatory requirement in any transport
network. That's one of the reasons why tandem connection monitoring is
specified.

Besides the need for E-NNIs, there is the need to interwork in the emerging
Ethernet/MPLS-TP based packet transport network the different characteristic
informations in the "transport service layer". The alternative is to stack
two "transport service layers" on top of each other. In this case MPLS-TP
can be required to support a ETH layer netowrk as its top transport service
layer, in order to get UNI-to-UNI monitoring of the transport service layer
signal with an endpoint in an Ethernet domain and an endpoint in an MPLS-TP
domain.

This interworking will be present already in many carrier networks (e.g.
metro domain uses Ethernet, core domain uses MPLS(-TP)), and must thus be
supported on I-NNI ports.

With Ethernet and TDM services expected to be the main services, we can
specify an MPLS-TP network in which the ETH layer takes care of UNI-to-UNI
transport service layer monitoring for all services types (p2p, p2mp, rmp,
mp2mp). In this case we can remove the MS-PW layer from the stack and simply
deploy SS-PWs as ETH link connections on ETH links supported by MPLS-TP
transport path layer signals (LSPs).

In my opinion there are a couple of choices in our industry for the packet
transport network:
1) use Ethernet VLAN based packet transport netowrk and stop MPLS-TP and
other PTN technology developments
   ==> irrealistic in my opinion

2) use MPLS-TP based packet transport entwork and stop Ethernet VLAN and
other PTN technology developments
   ==> irrealistic in my opinion

3) use Ethernet VLAN technology as common "transport service layer"
technology in all PTN alternatives (Ethernet VLAN, MPLS-TP, PBB-TE)
   ==> MPLS-TP could be specified with such Ethernet VLAN transport service
layer for p2p, p2mp, rmp and mp2mp services... If done, there is no peer-IW
necessary between service VLAN and MS-PW for p2p and p2mp transport service
layer connections... And we don't need a MS-PW layer in the MPLS-TP layer
stack.
   ==> I don't think this option will get enough support from MPLS side

4) same as 3), but with MS-PW layer in the MPLS-TP layer stack as second
transport service layer (located between  Ethernet VLAN transport service
layer and MPLS-TP transport path layer)
   ==> introduces additional complexity in MPLS-TP UNI-N, I-NNI and E-NNI
ports on PE type nodes
   ==> introduces additional network management complexity in packet
transport networks as in part of the PTN two transport service layers are to
be managed
   ==> if you like increased CAPEX and OPEX of your PTN then this is the
choice

5) use service VLAN to MS-PW peer-interworking in the transport service
layer and specify MS-PW OAM and protection switching on the basis of Y.1731
and G.8031
   ==> interworking will be mostly limited to replacement of 32-bit VLAN Tag
by a 32-bit LSE Header
   ==> seems to be the better option...

Peer-interworking of p2p/p2mp service VLAN with p2p/p2mp MS-PW is
interworking of compatible transport entities. Both types of transport
entity include a "broadcast forwarding rule" and do not include any other
forwarding or filtering rules.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 23 januari 2009 10:42
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mpls-tp] Layer networks and sublayers in MPLS-TP

Maarten wrote to Ben (snipped to key point):
22 January 2009 22:49

> As this seems not to be obvious to you (and most likely others), I 
> propose to explicitly document this minimized layer stack approach 
> (with ETH channel layer as a client of MPLS-TP path/LSP layer ntwork) 
> in the MPLS-TP framework document. And it has to be documented in the 
> I-NNI and E-NNI standards
> (G.8112) to make interworking between equipment from different vendors 
> and operators possible.

Don't bother.  The 'this seems not to be obvious' problem does not lie with
us (where I think can speak for the majority) but with you I am afraid
Maarten.

So let me repeat what I have said before about this nonsense of creating
E-NNIs and trying to force the industry to take up peer-partition I/W:

Who says we will have E-NNIs here anyway?  How many operators have asked for
this....can they please make their presence known (this is the 4th time I
have asked this question, the previous 3 'asks' had no responses)?

I know all the 'Implementation Agreement Fora' like MPLSF, MEF, ATMF, etc
have always pushed for NNIs and UNIs when promoting their technology
without, it would seem, understanding the bigger problem...and IMO this is a
very disingenuous and dangerous practice that they should stop.

This situation gets significantly worse if we try and I/W different
technologies as E-NNIs...like Ethernet and MPLS-TP...and much, much worse if
this is then between different operating parties. 

I know some people are thinking of doing this (job creation?  industry
sabotage?) but technically it is a complete waste of time/money (it's not
even a trivial protocol conversion exercise anyway across all DP/CP
components, and operators would never allow this in the MP for security
reasons).

But suppose someone was indeed daft enough to do this, then once one comes
to the end of a concatenated sequence of peer-interworked non top-of-stack
technologies one still has to look upwards to see another end-end *layer
network* above you that is top-of-stack and does have end-system application
adaptation functions, ie truly interfaces with real *external*
message/file/stream applications....noting that this (communication between
agents external to the networks) is the whole raison d'etre for networking
at all (the lower layer peer-interworked entities have no value at all
without this)!

So what one *MUST* conclude here is that we should never have bothered
peer-interworking the server layer network technologies, and instead just
fully terminated them at the I/W point and simply passed the higher client
layer network transparently in the 1st place....because that is all we end
up doing once we get to the end of a sequence of lower layer
concatenated/interworked peers anyway!!!  In plain English...we have just
burned a shed load of money.

This is so blindingly technically obvious/correct that I cannot believe
anyone in their right minds would even think of arguing against it. 

regards, Neil

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

---

From: <[email-masked]>
Date: Mon, 2 Feb 2009 11:04:18 -0000

Maarten Vissers wrote 02/02/2009 09:38

Neil,

MEF has an active E-NNI project. 

NH=> Yes I know.  So has MPLSF, so did ATM, so did FRF......there is tendency for such fora to push their technology bent on the world, even in ways that are not sensible.  But how many E-NNIs between different party's networks do you find out there today in each of these technologies?  I'll wager not many (if any).  

Now look at Internet and PSTN....E-NNIs everywhere! 

You may like to ponder on why this is....but if not clear let me again explain it.

When you do the analysis you find that E-NNIs (whether between partitions of the same technology (best case) or different modes/technologies (worst case)) are not much use IF the layer network you are dealing with is NOT top-of-stack and interfaces with external CPE which generate message/file/stream applications.

So when not top-of-stack and carrying another layer network (that itself may or may not be top-of-stack) then the only logical conclusion is to fully terminate the server layers at the I/W points and simply pass the client transparently.

If you don't do this then all you achieve is the creation of a load of unnecessary work/cost because when you finally arrive at the end of such a concatenated sequence of interworked server layer networks you still have to fully terminate them and pass the client there transparently!  So you might as well have done this in the 1st place and saved yourself a whole shed load of cost/grief.

If I build an IP (or whatever) network where the link connections may be from SDH VC4, E3, T3, Ethernet, etc then I DO NOT interwork any of these lower layer networks as peers....they fully terminate at each IP layer node.

If this is not obvious to everyone then I am in total despair....because the logic here is irrefutable.  

So, *for the 5th time of asking* (with only Maarten responding saying he wants them) can we have a clear showing of support for E-NNIs with peer interworking between MPLS-TP and other technologies owned by other parties....but let's make this last point specific to the MPLS-TP<=>Ethernet case for now.

And Ben I believe there is nothing in the MPLS-TP requirements draft on this either...so if there is no support then this should stay this way.

regards, Neil

As there are many carriers in this world,
and as customers want connectivity irrespective of the specific carrier
present in a domain, E-NNIs are a mandatory requirement in any transport
network. That's one of the reasons why tandem connection monitoring is
specified.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 23 januari 2009 10:42
To: [email-masked]; [email-masked];
[email-masked]

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 12:50:49 +0100

Neil,

Peer interworking in a packet transport netowrk is not locked to E-NNIs.
Peer interworking of service VLAN with MPLS-TP PW may be required inside one
carrier's network, i.e. on an I-NNI. As such peer-interworking is to be
addressed independent of E-NNI.

I find your implied statement on multi-carrier service supports remarkable.
Do I understand it correctly that you don't forsee any multi-carrier service
requirements in packet transport networks? I.e. that the packet transport
network of each carrier will be a stand-alone network without any
interconnections with packet transport networks of other carriers?

My expectation is in such case definitely not aligned with your expectation.
I expect that there will be a world-wide packet transport network in the
future, which supports p2p, p2mp, rmp and mp2mp services between n points in
the world; i.e. "global interconnect". An e.g. business customer with
locations in Japan, UK, USA, China can get e.g. a 4-port mp2mp E-LAN service
supported by the packet transport network. Another customer with locations
in Germany and UK can get a 2-port E-LINE service supported by the same
packet transport network.

This PTN is the packet service optimized version of today's world wide SDH
network, in which one can get an SDH VC-n connection with endpoints in
different carrier networks for many years now. This implies that there are
E-NNIs in the SDH network. Your SDH network is connected to many other
carrier SDH networks as far as I know.

The hybrid Ethernet and MPLS(-TP) packet transport network will be required
to support services of which the endpoints are in the domains of multiple
carriers. As such we will get those carrier domains interconnected via E-NNI
interfaces. The data planes for those interfaces are the data planes for the
I-NNI interfaces plus some TCM endpoints; i.e. well known processing.
Multi-carrier transport service connection set up can be done via network
management, similar as done today in SDH. Or it can be done with the help of
a control plane, in which case it is necessary to specify the E-NNI control
plane details.

The transport service layer is the **top-of-stack** layer in a transport
network. Peer interworking (G.805 layer netowrk interworking) is taking
place at the transport network's top-of-stack layer, and all server layer
signals (phy media, section, transport path layer signals) in this transport
network are terminated before interworking is performed.

Let's continue this discussion in front of a white board.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 februari 2009 12:04
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Layer networks and sublayers in MPLS-TP

Neil,

NH=> Yes I know.  So has MPLSF, so did ATM, so did FRF......there is
tendency for such fora to push their technology bent on the world, even in
ways that are not sensible.  But how many E-NNIs between different party's
networks do you find out there today in each of these technologies?  I'll
wager not many (if any).  

You may like to ponder on why this is....but if not clear let me again
explain it.

When you do the analysis you find that E-NNIs (whether between partitions of
the same technology (best case) or different modes/technologies (worst
case)) are not much use IF the layer network you are dealing with is NOT
top-of-stack and interfaces with external CPE which generate
message/file/stream applications.

So when not top-of-stack and carrying another layer network (that itself may
or may not be top-of-stack) then the only logical conclusion is to fully
terminate the server layers at the I/W points and simply pass the client
transparently.

If you don't do this then all you achieve is the creation of a load of
unnecessary work/cost because when you finally arrive at the end of such a
concatenated sequence of interworked server layer networks you still have to
fully terminate them and pass the client there transparently!  So you might
as well have done this in the 1st place and saved yourself a whole shed load
of cost/grief.

If I build an IP (or whatever) network where the link connections may be
from SDH VC4, E3, T3, Ethernet, etc then I DO NOT interwork any of these
lower layer networks as peers....they fully terminate at each IP layer node.

If this is not obvious to everyone then I am in total despair....because the
logic here is irrefutable.  

So, *for the 5th time of asking* (with only Maarten responding saying he
wants them) can we have a clear showing of support for E-NNIs with peer
interworking between MPLS-TP and other technologies owned by other
parties....but let's make this last point specific to the MPLS-TP<=>Ethernet
case for now.

And Ben I believe there is nothing in the MPLS-TP requirements draft on this
either...so if there is no support then this should stay this way.

regards, Neil

As there are many carriers in this world, and as customers want connectivity
irrespective of the specific carrier present in a domain, E-NNIs are a
mandatory requirement in any transport network. That's one of the reasons
why tandem connection monitoring is specified.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 23 januari 2009 10:42
To: [email-masked]; [email-masked];
[email-masked]

regards, Neil

---

From: <[email-masked]>
Date: Mon, 2 Feb 2009 13:32:16 -0000

Maarten

who wrote 02 February 2009 11:51
<snipped>
 
> I find your implied statement on multi-carrier service 
NH=> Not sure why...the logic is simple to follow and it reflects
reality.

> Do I understand it correctly that you don't forsee any 
> multi-carrier service requirements in packet transport 
> networks? I.e. that the packet transport network of each 
> carrier will be a stand-alone network without any 
NH=> Yes...at least for your interpretation of what this means.  But we
do already interconnect as peers in a packet network...its called the
*public services Internet*.  And this is because it's a top-of-stack
network with message/file/stream application adaptation functions (eg
UDP/TCP/RTP).  These don't exist in MPLS-TP or Ethernet (or of course
SDH), so unless you are planning to add their support too in your
proposals then the simple technical solution is *do not peer interwork
them.*...it really is that simple. 

> My expectation is in such case definitely not aligned with 
NH=> I know...your expectation is however not aligned with what
operators want and will do.
<snipped>

> 
> This PTN is the packet service optimized version of today's 
> world wide SDH network, in which one can get an SDH VC-n 
> connection with endpoints in different carrier networks for 
> many years now. This implies that there are E-NNIs in the SDH 
> network. Your SDH network is connected to many other carrier 
> SDH networks as far as I know.
NH=> You are wrong on this.  I also double-checked with our SDH Network
Designers before I responded just to be 100% sure.  We only provide very
low level functional physical layer aggregate interconnects (so that any
clients can be carried as a transparent bit-sequence-preserved
stream)...but these are for sure not E-NNIs. There is no CP I/W (and our
designers would not go here even if they could) and the MP is
consciously blanked out.  The DP access point 'addressing' is by
bi-lateral agreement.

To call these 'E-NNIs' is bestowing them with a behaviour they just
don't have  ....they are simply convenient, low functionally,
bottom-of-stack p2p (ie never truly networked) section layer physical
interfaces......because *something* has to provide the physical section
layer interface between different parties so that the networks that do
provide public services and have real E-NNIs (ie PSTN, Internet) can
connect together.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:49:13 +0000

Maarten,

> interconnections with packet transport networks of other carriers?

I will have standalone network foo, another operator will have standalone
network bar. If we are supporting a service X across the concatenation of
our networks then what matters is X. foo and bar do not need to interwork
directly with each other beyond being able to pass X from foo to bar as Neil
describes.

> packet transport network.

But what matters is that the different transport networks can support E-LAN
and E-LINE services not that they can peer interwork directly with one
another.

> carrier SDH networks as far as I know.

But it just hands "data" over the fence as a bitstream.  Our SDH network
doesn't peer interwork with others carrier's AFAIK.
 
Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Feb 2009 12:17:01 +0100

Ben,

If networks foo and bar support a service X (e.g. E-LIEN, E-LAN), then the
foo+bar networks must support UNI-to-UNI monitoring of the transport service
layer isntance that supports this service X. It is as such extremely
important that there is interworking at the transport service layer, as it
is not desirable to go back to the customer's layer.

I have checked with some of your colleagues and they tell me that your
network has SDH E-NNIs with other operators (e.g. mobile operators in UK and
"other local operators" outside the UK). Especially the international
service delivery depends heavily on such E-NNI's, which are STM-N interfaces
with VC-n signals in it. I am also told that for international ethernet
services there are E-NNIs (at Ethernet VLAN and Ethernet PHY level) in use;
both 1 service (VLAN) per PHY (e.g. FE) and multiple services (VLANs) per
PHY (1GE) are in use. Without such Ethernet E-NNIs those services would in
many cases not be able to be delivered.

Note that there would be three types of E-NNI:
1) data plane only E-NNI (MP/CP blocked)
2) data and management plane E-NNI (CP blocked)
3) data, management and control plane E-NNI.

Most E-NNIs in a transport network are type 1 E-NNIs (data plane only).

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 3 februari 2009 0:49
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Maarten,

On 02/02/2009 11:50, "Maarten Vissers" <[email-masked]> wrote:

> Peer interworking of service VLAN with MPLS-TP PW may be required 
> inside one carrier's network, i.e. on an I-NNI. As such 
> peer-interworking is to be addressed independent of E-NNI.
> 
> Do I understand it correctly that you don't forsee any multi-carrier 
> service requirements in packet transport networks? I.e. that the 
> packet transport network of each carrier will be a stand-alone network 
> without any interconnections with packet transport networks of other
carriers?

> I expect that there will be a world-wide packet transport network in 
> the future, which supports p2p, p2mp, rmp and mp2mp services between n 
> points in the world; i.e. "global interconnect". An e.g. business 
> customer with locations in Japan, UK, USA, China can get e.g. a 4-port 
> mp2mp E-LAN service supported by the packet transport network. Another 
> customer with locations in Germany and UK can get a 2-port E-LINE 
> service supported by the same packet transport network.

> This PTN is the packet service optimized version of today's world wide 
> SDH network, in which one can get an SDH VC-n connection with 
> endpoints in different carrier networks for many years now. This 
> implies that there are E-NNIs in the SDH network. Your SDH network is 
> connected to many other carrier SDH networks as far as I know.

Ben

> 
> The hybrid Ethernet and MPLS(-TP) packet transport network will be 
> required to support services of which the endpoints are in the domains 
> of multiple carriers. As such we will get those carrier domains 
> interconnected via E-NNI interfaces. The data planes for those 
> interfaces are the data planes for the I-NNI interfaces plus some TCM
endpoints; i.e. well known processing.
> Multi-carrier transport service connection set up can be done via 
> network management, similar as done today in SDH. Or it can be done 
> with the help of a control plane, in which case it is necessary to 
> specify the E-NNI control plane details.
> 
> The transport service layer is the **top-of-stack** layer in a 
> transport network. Peer interworking (G.805 layer netowrk 
> interworking) is taking place at the transport network's top-of-stack 
> layer, and all server layer signals (phy media, section, transport 
> path layer signals) in this transport network are terminated before
interworking is performed.
> tendency for such fora to push their technology bent on the world, 
> even in ways that are not sensible.  But how many E-NNIs between 
> different party's networks do you find out there today in each of 
> these technologies?  I'll wager not many (if any).
> 
> When you do the analysis you find that E-NNIs (whether between 
> partitions of the same technology (best case) or different 
> modes/technologies (worst
> case)) are not much use IF the layer network you are dealing with is 
> NOT top-of-stack and interfaces with external CPE which generate 
> So when not top-of-stack and carrying another layer network (that 
> itself may or may not be top-of-stack) then the only logical 
> conclusion is to fully terminate the server layers at the I/W points 
> and simply pass the client transparently.
> 
> unnecessary work/cost because when you finally arrive at the end of 
> such a concatenated sequence of interworked server layer networks you 
> still have to fully terminate them and pass the client there 
> transparently!  So you might as well have done this in the 1st place 
> and saved yourself a whole shed load of cost/grief.
> 
> If I build an IP (or whatever) network where the link connections may 
> be from SDH VC4, E3, T3, Ethernet, etc then I DO NOT interwork any of 
> these lower layer networks as peers....they fully terminate at each IP
layer node.
> 
> If this is not obvious to everyone then I am in total 
> despair....because the logic here is irrefutable.
> 
> So, *for the 5th time of asking* (with only Maarten responding saying 
> he wants them) can we have a clear showing of support for E-NNIs with 
> peer interworking between MPLS-TP and other technologies owned by 
> other parties....but let's make this last point specific to the 
> MPLS-TP<=>Ethernet case for now.
> 
> And Ben I believe there is nothing in the MPLS-TP requirements draft 
> on this either...so if there is no support then this should stay this way.
> 
> regards, Neil
> 
>  
> 
>  
> 
>  
> 
> As there are many carriers in this world, and as customers want 
> connectivity irrespective of the specific carrier present in a domain, 
> E-NNIs are a mandatory requirement in any transport network. That's 
> one of the reasons why tandem connection monitoring is specified.
> 
> Besides the need for E-NNIs, there is the need to interwork in the 
> emerging Ethernet/MPLS-TP based packet transport network the different 
> characteristic informations in the "transport service layer". The 
> alternative is to stack two "transport service layers" on top of each 
> other. In this case MPLS-TP can be required to support a ETH layer 
> netowrk as its top transport service layer, in order to get UNI-to-UNI 
> monitoring of the transport service layer signal with an endpoint in 
> an Ethernet domain and an endpoint in an MPLS-TP domain.
> 
> metro domain uses Ethernet, core domain uses MPLS(-TP)), and must thus 
> be supported on I-NNI ports.
> 
> With Ethernet and TDM services expected to be the main services, we 
> can specify an MPLS-TP network in which the ETH layer takes care of 
> UNI-to-UNI transport service layer monitoring for all services types 
> (p2p, p2mp, rmp, mp2mp). In this case we can remove the MS-PW layer 
> from the stack and simply deploy SS-PWs as ETH link connections on ETH 
> links supported by MPLS-TP transport path layer signals (LSPs).
> 
> In my opinion there are a couple of choices in our industry for the 
> packet transport network:
> 1) use Ethernet VLAN based packet transport netowrk and stop MPLS-TP 
> and other PTN technology developments
> 2) use MPLS-TP based packet transport entwork and stop Ethernet VLAN 
> and other PTN technology developments
>    ==> MPLS-TP could be specified with such Ethernet VLAN transport 
> service layer for p2p, p2mp, rmp and mp2mp services... If done, there 
> is no peer-IW necessary between service VLAN and MS-PW for p2p and 
> p2mp transport service layer connections... And we don't need a MS-PW 
> layer in the MPLS-TP layer stack.
> 4) same as 3), but with MS-PW layer in the MPLS-TP layer stack as 
> second transport service layer (located between  Ethernet VLAN 
> transport service layer and MPLS-TP transport path layer)
>    ==> introduces additional complexity in MPLS-TP UNI-N, I-NNI and 
> E-NNI ports on PE type nodes
> transport networks as in part of the PTN two transport service layers 
> are to be managed
>    ==> if you like increased CAPEX and OPEX of your PTN then this is 
> the choice
> 
> 5) use service VLAN to MS-PW peer-interworking in the transport 
> service layer and specify MS-PW OAM and protection switching on the 
> basis of Y.1731 and G.8031
>    ==> interworking will be mostly limited to replacement of 32-bit 
> VLAN Tag by a 32-bit LSE Header
> entity include a "broadcast forwarding rule" and do not include any 
> other forwarding or filtering rules.
> 
> Regards,
> Maarten
> 
> 
> 
> 
>> (G.8112) to make interworking between equipment from different 
>> vendors and operators possible.
> 
> Don't bother.  The 'this seems not to be obvious' problem does not lie 
> with us (where I think can speak for the majority) but with you I am 
> afraid Maarten.
> 
> So let me repeat what I have said before about this nonsense of 
> creating E-NNIs and trying to force the industry to take up peer-partition
I/W:
> 
> Who says we will have E-NNIs here anyway?  How many operators have 
> asked for this....can they please make their presence known (this is 
> the 4th time I have asked this question, the previous 3 'asks' had no
responses)?
> 
> I know all the 'Implementation Agreement Fora' like MPLSF, MEF, ATMF, 
> etc have always pushed for NNIs and UNIs when promoting their 
> technology without, it would seem, understanding the bigger 
> problem...and IMO this is a very disingenuous and dangerous practice that
they should stop.
> technologies as E-NNIs...like Ethernet and MPLS-TP...and much, much 
> worse if this is then between different operating parties.
> 
> sabotage?) but technically it is a complete waste of time/money (it's 
> not even a trivial protocol conversion exercise anyway across all 
> DP/CP components, and operators would never allow this in the MP for 
> security reasons).
> 
> But suppose someone was indeed daft enough to do this, then once one 
> comes to the end of a concatenated sequence of peer-interworked non 
> top-of-stack technologies one still has to look upwards to see another 
> end-end *layer
> network* above you that is top-of-stack and does have end-system 
> application adaptation functions, ie truly interfaces with real 
> *external* message/file/stream applications....noting that this 
> (communication between agents external to the networks) is the whole 
> raison d'etre for networking at all (the lower layer peer-interworked 
> entities have no value at all without this)!
> 
> peer-interworking the server layer network technologies, and instead 
> just fully terminated them at the I/W point and simply passed the 
> higher client layer network transparently in the 1st place....because 
> that is all we end up doing once we get to the end of a sequence of 
> lower layer concatenated/interworked peers anyway!!!  In plain 
> English...we have just burned a shed load of money.
> 
> This is so blindingly technically obvious/correct that I cannot 
> believe anyone in their right minds would even think of arguing against
it.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:25:42 +0000

Maarten,

If I understand your use of E-NNI in this context correctly then what you
really describe is a static interconnection between networks where traffic
is passed between them. In the example you give both networks are of the
same technology.

I don't see a need to specifically articulate this as a requirement it is
implicit in the requirement

MPLS-TP MUST support transport paths through multiple homogeneous domains.

Ben