Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

From: [email-masked]
Date: Mon, 4 May 2009 16:38:07 +0800

Hi Neil,

There is always another layer network Y above a non top-of-stack layer 
network X, so we CAN terminate X and just pass Y across at border nodes. 
But I doubt if passing Y across is the best way to connect two same 
technology networks. 
For example, if we want to transport Eth signal through two parties of SDH 
network, AFAIK in most case of real deployment, it is VC4, not Eth, that 
pass across the border, shown in following figure. I think Retrieving 
Eth_CI from VC4_CI is much complex than Using SDH ENNI.

Reguard,
Suhui.

(part A)                                (part B)
----------------------------------------
|   Eth           Eth       Eth           |
----------------------------------------
|   VC4          VC4             VC4       |
----------------------------------------
|  MS/RS |        | MS/RS |      |  MS/RS | 
--------           --------       --------

<[email-masked]> 
2009-04-30 14:28

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport 
path    requirements)

Thanks Suhui

From: [email-masked] [mailto:[email-masked]] 
Sent: 30 April 2009 03:00
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
transport path requirements)

Hi Neil, 

I think I misunderstood the words ‘top-of-stack network’ , It doesn’t 
mean a network is actually at top of the stack, so no matter what layer IP 
network is actually at, IP network is always a ‘top-of-stack network’ 
because it can ‘support external message/file/stream applications’. Is 
my understanding right? 
 
NH=> Yes.   There is probably a better term for it, but it was the 
expression that first came to mind when I wanted a shorthand way to 
define:
-    the network that directly supports external applications - 
top-of-stack.
-    the  network that modulates the EM wave on metallic/optical/radio 
media - bottom-of-stack
 
Note - some network technologies cannot currently fulfil either of these 
roles....indeed MPLS is like this. 
Both these networks must be present in all practical networking 
situations:
-    if the former is not present the networking of the lower layers is 
serving no purposes;
-    if the latter is not present we cannot send information across 
geographic distance......and just as I and Deborah have repeatedly pointed 
out the mere that there is physical interface/connection here does *not* 
mean this is an E-NNI. 
 
An E-NNI must consider all DP and CP components that are used by an 
operating party in their own domain for some network mode/technology 
X.....so this is much more than simply OAM.  In particular it must 
consider the DP interworking of the end-system application adaptation 
functions that support external message/file/stream applications, and if 
these are *not* present then network X MUST be supporting a higher layer 
network Y by definition.  We therefore observe that peer-partition 
interworking at network X is not necessary.  Network X can be fully 
terminated at the interworking point and network Y passed transparently. 
The above is recursive upwards until we come to the real top-of-stack 
network and it is here that E-NNIs are essential.....and indeed this is 
exactly what we see for the public networks of the Internet and the PSTN.

But I still cannot agree the assertion that ‘any non top-of-stack network 
has no need for E-NNI peer-partition working between different operating 
parties’. As you said SDH is not a top-of-stack network, but VC4 
connections can pass through multi operator’s domains, so the interface 
between different domains is E-NNI.  
 
NH=> No, this is not correct.  We can of course create E-NNIs for any 
network/mode we like, but what I am showing is that this is not 
technically necessary for networks that are not top-of-stack.  In fact it 
is actually much more serious than simply "not necessary", because when 
you create such peer-partitions between different parties you are forcing 
them to evolve their networks (that have such peer partitions) in 
lock-step (and there are also regulatory factors to consider here - also 
see Aside below).   For the vast majority of practical situations a 
client/server relationship is more relevant, safer and important.
 
This situation would be even more unacceptable should such peer-partitions 
be between different modes/technologies, eg Ethernet and MPLS 
interworking.  This is most definitely not a good idea and we in BT will 
not support this. 
 
Aside=> This does not prevent operating parties having private bilateral 
peer-partition relationships in some non top-of-stack network technology.  
However, this would need to consider any legal/commercial regulatory 
framework that is in force where this is being considered.
 
Neil Harrison
Chief Network Operations Strategist
BT Innovate

Tel: +44 (0) 1 604 820 052
Email: [email-masked]
Web: www.bt.com 
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 

Regards, 
Suhui. 

<[email-masked]> 
2009-04-29 18:21 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
       requirements)

Thanks Suhui......sorry I missed your specific question....have a look 
in-line and see if this helps. 

From: [email-masked] [mailto:[email-masked]] 
Sent: 29 April 2009 10:31
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
transport path requirements)

Hi Neil， 

Thanks for your rapid reply. 
I am confused by your comments, are you suggesting 
EverythingoverIPoverMPLS-TP? AFAIK, MPLS-TP can carry many kinds of 
clients, not just IP.In my example, E1overPWoverMPLS-TP, there is no IP 
layer at all.   
 
NH=> Fully understand.  I was giving IP as an *example* of a technology 
that can support real external applications because it has 
message/file/stream application adaptation functions in the form of 
UDP/TCP/RTP.   In the case of E1 that you note (as E1overPWoverMPLS-TP) 
you have to ask yourself what specific *external* applications does the E1 
support here?.....always remembering that *any* networking technology MUST 
ultimately support some form of *externally sourced* information source 
else it is not serving any purpose.  So just supporting E1 on its own does 
not provide this....for example ask yourself how voice or any type of 
message/file data gets carried by the E1. 
 
And you don’t answer my question: IP is a top-of-stack network in the 
case of E1overPWoverIP, why doesn't MPLS-TP be a top-of-stack network in 
the case of E1overPWoverMPLS-TP? They are at the same position in the 
stack, and I think E1 is ‘real external stream applications’ 
  
NH=> The point here is that *any* network mode/technology (be it cl-ps, 
co-ps or co-cs) can act as the server for any other mode/technology. 
However, not all technologies can support external applications.....to 
support these the technology must have application adaptation functions 
for the message/file/stream information sources that are generated in 
external CPE, eg phone, PC, etc. 
  
Most technologies do not have these external application adaptation 
functions and so the only job they can do is create the topology of other 
layer networks. 
  
So yes we can use IP (cl-ps) to carry SDH VC4 (co-cs) if we 
want.......probably not a good idea but it is for sure possible.  However, 
an SDH VC4 network cannot *directly* support either voice or data but an 
IP network can.....because IP has UDP/TCP/RTP applications adaptations and 
SDH VC4 does not have these.  Having said that, there is in principle no 
reason why any mode/technology (even SDH VC4) cannot support external 
message/file/stream applications......its just that for most technologies 
these have never been specified because they were only ever intended to 
provide a 'network builder' transport role. 
  
Aside=> If a technology X can support message/file/stream applications 
directly then here we would most definitely have to consider 
peer-interworking technology X with both IP (Internet) and PSTN (voice 
case only).  In all other cases (ie where technology X is not 
top-of-stack, ie does not have message/file/stream application adaptation 
functions) there is no need for peer-interworking it with any other 
technology, including IP (Internet) and PSTN. 

Your final point ("I think E1 is ‘real external stream applications’" ) 
is not strictly correct but I can fully understand why you say this.  E1 
belongs to the co-cs mode.  When you analyse this (as is done in G.800, 
which explains why the 3 network modes arise from information/systems 
theory considerations) you find that in the time dimension the co-cs mode 
partitions resource (time) up into regular time slices....so this means 
both the start epoch (an implicit label) and (most crucially) its duration 
are fixed.   
  
Without going into major detail here (I have paper on this I can send you 
if you want...just ask) what this means is that the co-cs mode is the 
ultimate 'smoother/shaper' for client traffic......so as you rightly 
observe this looks like a stream case.  It's not a specific external 
application however like human voice or video (these must generate real 
*information* that communicating parties understand) but it for sure has 
the CBR behaviour of a stream. 
  
BTW the reason the co-cs mode has been enduringly successful as a 
transport network is because it provides *transparency* to all clients 
(which is exactly the similar behaviour of a stream as you note), ie 
-    all client bits treated equally (a really key point this, as this 
means it provides equal 'importance' treatment of the ultimate higher 
level (and unseen/unknown by the co-cs transport network) 
message/file/stream applications) 
-    client bit ordering is preserved 
-    does not try an infer meaning of client bits nor change them 
-    ensures the traffic behaviour of client X cannot impact the 
performance experienced by party Y. 

regards, Neil 

Regards, 
Suhui. 

<[email-masked]> 
2009-04-29 14:40 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path  
requirements)

Thanks Shuhui, 
 
Do not confuse physical interconnect with E-NNI.....I'll come back on this 
shortly when discussing the bottom-of-stack section layer. 
 
The first thing to understand is that *all* networks are there to 
ultimately support one purpose.....and that is to allow communications 
between parties that are *external* to the networks.  So everything we do 
in networking is there to ultimately support this objective.  What this 
means is that the DP of some network (what I call the top-of-stack 
network) MUST be providing adaptation functions for these external 
applications.......and these can generically be classified as messages, 
files and streams. 
 
We can see that IP is a top-of-stack network as it has UDP/TCP/RTP (for 
example) adaptations.  ATM was also once (~90s) intended to be a 
top-of-stack network and it had its own application adaptations in the 
form of AALs.  At one stage there were 5 of these, but in practice only a 
couple were really successful because of the generic nature of 
message/file/stream classification.  The PSTN is also top-of-stack, and 
its application adaptation was mainly for voice (stream) support. 
 
Most other networks do not have these application adaptation 
functions....so they do not directly support applications.  What this 
means in practice is that these networks (a list which includes PDH, SDH, 
OTN, Ethernet, MPLS) MUST carry a further layer network above them that is 
top-of-stack....like IP.  There is no choice in the matter here.  So 
whilst we might say that an MPLS network is carrying an E1 PW the E1 
entity must in turn be carrying some other top-of-stack network (like IP 
or PSTN), else it is serving no ultimate purpose. 
 
Now in order to transmit information over geographic distance we must 
modulate an EM wave on some metallic/optical/radio media....this is the 
bottom-of-stack section layer.  These are high bit rate transport pipes 
whose function is to provide transparent (which I have defined previously) 
transport to whatever client layers networks sit above them....and where, 
as I noted above, there MUST be a top-of-stack network present as the 
ultimate layer network client else there is not external party 
communication possible. 
 
So when we connect together 2 top-of-stack networks we do so at a section 
layer which is invariably carrying a very large aggregate of 
applications.....and of course these applications can be a time varying 
mix of message/file/stream cases with a set of unknown (to the section 
layer) importance's (ergo why transparency is an essential requirement in 
transport networks). 
 
The real E-NNIs (which considers both DP and CP components....we never 
usually peer the MP, and we restrict the scope of the CP) exist in the 
top-of-stack layer network.  The section layer interconnect is a dumb DP 
pipe...it just shifts bits transparently and maintains their ordering. 
There is no concept of CP (or MP) peering on these bottom-of-stack section 
layer interconnects. 
Aside=> In some countries these interconnects have to be carefully 
specified in order to distinguish regulated and unregulated 
services.....so there are important legal/commercial considerations here, 
it is not simply a technical issue. 
 
We can of course create E-NNIs in non top-of-stack layer networks (we can 
do many things that are not useful).  So lets assume we do this.....and 
lets assume we choose MPLS since you mention this in the mail below. 
 
Now how do external parties who wish to communicate interface with this 
MPLS network?  Can you support all types of message/file/stream 
applications *directly* into MPLS?  In principle you could if you allowed 
MPLS to have end system application adaptations such as UDP/TCP/RTP or the 
like.  But these don't exist today, and in the most usual case the MPLS 
network will carry an IP layer network because this can support the 
message/file/stream applications. 
 
We can go through exactly the same analysis with any network that is not 
top-of-stack, eg Ethernet.  And when you do this what you realise is that 
although we can create peer interworking of MPLS (or whatever) this has 
not really helped since we might as well have just terminated the MPLS 
network and passed the IP layer across. 
 
Now the above becomes even more striking in its importance if you consider 
peer interworking of 2 different non top-of-stack networks....lets pick 
MPLS and Ethernet because that is what is often mentioned.   
 
What we have to do now at the E-NNIs between Ethernet and MPLS is go 
through each DP and CP component and do a 'protocol conversion' exercise 
where required......and the first problem you will encounter is that there 
will be lots of functional mismatch.  Moreover if one or both of the 
networks can support multiple CP types like MPLS can, eg RSVP-TE 
signalling, LDP signalling, BGP4 'signalling', OSPF routing, IS-IS 
routing.....and I could list similar for Ethernet.....you are going to 
have to consider each pairing case in turn.  A lot of work. 
 
And when you have done all this you ask the question 'what is it that 
carries the real external message/file/stream applications in the DP 
here?'.......and now you find no native support for these in MPLS or 
Ethernet, but what we do find is that both of them are carrying IP because 
this does support the external applications.  Now at this point we have 
discovered what is the common thing between MPLS and Ethernet....it is the 
top-of-stack IP layer network.  And so we ultimately realise we could have 
save ourselves a load of unnecessary work by simply terminating the MPLS 
and Ethernet layer network at the interworking point and just passed the 
IP layer network across. 
 
Sorry I've had to go through all this yet again (esp for all the folks 
that have already understood the point) but I do hope its clear now and we 
can put this issue to bed. 
 
regards, Neil 

From: [email-masked] [mailto:[email-masked]] 
Sent: 29 April 2009 03:22
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
transport path requirements)

Hi Neil, 

‘it is quite clear from a simple technical analysis that any non 
top-of-stack network has no need for E-NNI peer-partition working between 
different operating parties.’ 

I cannot agree this statement. 
For example, there are two IP networks belonging to two operators, a E1 is 
transported from A network to B network (e.g. E1overPWoverIP ), IP 
packet(not E1) pass across form A to B at border node, so there is a E-NNI 
between these  two IP network. In this case, is IP a top-of-stack network? 

Now let us replace IP networks by MPLS-TP networks (e.g. 
E1overPWoverMPL-TP), MPLS-TP network is at same position in the stack as 
IP network is, why can IP network have E-NNI but MPLS-TP cannot? 

Regard, 
Suhui 
<[email-masked]> 
发件人:  [email-masked] 
2009-04-28 14:43 

收件人
<[email-masked]>, <[email-masked]>, 
<[email-masked]> 
抄送
[email-masked] 
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

Huub wrote 27 April 2009 22:27
> 
> Hi Adrian,
> 
> You wrote:
> 
> > Isn't the solution here the same as the one I proposed for "TCM"?
> 
> Indeed, and that we do not have to around in circles about TCM.
> 
> How about:
> the requirement is that a server layer shall inform its clients
> that it has detected a service interuption, this to ensure that
> the clients can inhibit (unnecessary) alarms.

NH=> This only applies if the client/server binding is fixed.  And of
course way back in the 70s when binary all 1s popped out of the failed
TTL logic into the PDH transport hierarchy this was true.  Also: no
labels here and no client traffic units to create. 

Where the client can dynamically be re-routed in response to a server
failure the proposed text is not valid.  It is also not necessary that
the server has to keep track of where its client traffic routings have
moved to.  For example, if I create the topology of an IP layer network
with links provided by SDH, Ethernet, ATM, OTN, etc servers, and each of
these server links is provided by a different operator, then why should
the servers need have knowledge of where the IP flows have moved to in
response to a server layer failure when the new routes have been
calculated by the IGP in the IP layer network?  I can apply the same
logic to an SVC-based co-ps/co-cs mode client....indeed the co-cs mode
PSTN is like this.

These observations make it quite clear to me at least that just copying
the AIS behaviour of the old transport hierarchies that had fixed
client/server relationships is not a sensible thing to do.

IMO the only essential DP OAM requirement is that each layer network
should be self-sufficient wrt OAM and not rely on any server layer
primitives being passed upwards.

Moreover, it should also be noted that (i) the defects that can occur in
each of the 3 network modes are not the same and (ii) their OAM
requirements are not identically the same. So the OAM that applies to
the cl-ps mode (eg IP) is not the same as the OAM that applies to the
co-ps mode (eg MPLS-TP) and neither of these is identically the same as
the OAM that applies to the co-cs mode (eg SDH).

Note - The only point being considered here is the real client and
server traffic relationship.  The creation of a hierarchy of TCM
sublayers is a separate topic.  Further, it is quite clear from a simple
technical analysis that any non top-of-stack network has no need for
E-NNI peer-partition working between different operating parties.  So
this is also a separate issue.  However, I propose that this latter
point be captured in the MPLS-TP requirements draft due to its
stand-alone and generic importance, ie this applies to more than just DP
OAM.  Ben can you please consider this point as/when the MPLS-TP
requirements draft is updated.

regards, Neil

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Mon, 4 May 2009 10:48:24 +0100

Thanks Suihui,
 
The crucial factor here is who owns which layer networks are whether we are dealing with a private or public top-of-stack network case....I will come back on this point shortly.
 
As a general onservation however, it is not a trivial technical or commercial matter to interwork as peers any mode/technology network between different operating parties.  One has to consider all DP/CP (usually not MP) components.  If they are not identically the same in all DP/CP components one has protocol conversion issues to deal with.  And don't forget you now 'lock' the 2 (or more) parties involved wrt how *both* their networks and commercial services can evolve...and this will also have to consider the legal/regulatory framework in force in that country.  This is not a smart idea at all when the networks are not top-of-stack and have different party ownership.
 
In the case you show below then a critical issue to understand first is who owns which layer networks?  Are there 2 different parties wrt SDH VC4 or a single party?  Are there 2 different parties wrt Ethernet or a single party?  And what kind of network lies above Ethernet?...is it a private or public network case?
 
If there are different parties also at the Ethernet layer then my argument simply recurses upwards, ie one does *not* pass the Ethernet layer network transparently here but one terminates it and either:
-    passes the next layer network up transparently *irrespective of whether it is top-of-stack or not *  IF it  is owned by a single party
-    if the next network layer network up is top-of-stack AND it is a private network AND there is a bilateral peering agreement between the parties AND if there are no adverse regulatory considerations then one could peer interwork this case (but caveat emptor would be my advice);
-    if the next network layer network up is top-of-stack AND it is a public network (eg PSTN, Internet) then one will most definitel peer interwork this case
 
BTW In the case other Ethernet over SDH VC4 there will also be GFP adaptation.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 04 May 2009 09:38
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil, 
	
	There is always another layer network Y above a non top-of-stack layer network X, so we CAN terminate X and just pass Y across at border nodes. But I doubt if passing Y across is the best way to connect two same technology networks. 
	For example, if we want to transport Eth signal through two parties of SDH network, AFAIK in most case of real deployment, it is VC4, not Eth, that pass across the border, shown in following figure. I think Retrieving Eth_CI from VC4_CI is much complex than Using SDH ENNI. 
	
	Reguard, 
	Suhui. 
	
	(part A)                                (part B) 

<[email-masked]> 

2009-04-30 14:28 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	Thanks Suhui 

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 30 April 2009 03:00
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil, 
	
	I think I misunderstood the words ‘top-of-stack network’ , It doesn’t mean a network is actually at top of the stack, so no matter what layer IP network is actually at, IP network is always a ‘top-of-stack network’ because it can ‘support external message/file/stream applications’. Is my understanding right? 
	  
	NH=> Yes.   There is probably a better term for it, but it was the expression that first came to mind when I wanted a shorthand way to define: 
	-    the network that directly supports external applications -  top-of-stack. 
	-    the  network that modulates the EM wave on metallic/optical/radio media - bottom-of-stack 
	  
	Note - some network technologies cannot currently fulfil either of these roles....indeed MPLS is like this. 
	Both these networks must be present in all practical networking situations: 
	-    if the former is not present the networking of the lower layers is serving no purposes; 
	-    if the latter is not present we cannot send information across geographic distance......and just as I and Deborah have repeatedly pointed out the mere that there is physical interface/connection here does *not* mean this is an E-NNI. 
	  
	An E-NNI must consider all DP and CP components that are used by an operating party in their own domain for some network mode/technology X.....so this is much more than simply OAM.  In particular it must consider the DP interworking of the end-system application adaptation functions that support external message/file/stream applications, and if these are *not* present then network X MUST be supporting a higher layer network Y by definition.  We therefore observe that peer-partition interworking at network X is not necessary.  Network X can be fully terminated at the interworking point and network Y passed transparently.  The above is recursive upwards until we come to the real top-of-stack network and it is here that E-NNIs are essential.....and indeed this is exactly what we see for the public networks of the Internet and the PSTN. 

	But I still cannot agree the assertion that ‘any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties’. As you said SDH is not a top-of-stack network, but VC4 connections can pass through multi operator’s domains, so the interface between different domains is E-NNI.   
	  
	NH=> No, this is not correct.  We can of course create E-NNIs for any network/mode we like, but what I am showing is that this is not technically necessary for networks that are not top-of-stack.  In fact it is actually much more serious than simply "not necessary", because when you create such peer-partitions between different parties you are forcing them to evolve their networks (that have such peer partitions) in lock-step (and there are also regulatory factors to consider here - also see Aside below).   For the vast majority of practical situations a client/server relationship is more relevant, safer and important. 
	  
	This situation would be even more unacceptable should such peer-partitions be between different modes/technologies, eg Ethernet and MPLS interworking.  This is most definitely not a good idea and we in BT will not support this. 
	  
	Aside=> This does not prevent operating parties having private bilateral peer-partition relationships in some non top-of-stack network technology.   However, this would need to consider any legal/commercial regulatory framework that is in force where this is being considered. 

	Neil Harrison
	
	Tel: +44 (0) 1 604 820 052
	Email: [email-masked] <mailto:[email-masked]> 
	Web: www.bt.com <http://www.bt.com/>  
	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 

	Regards, 
	Suhui. 

<[email-masked]> 

2009-04-29 18:21 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	

	Thanks Suhui......sorry I missed your specific question....have a look in-line and see if this helps. 

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 29 April 2009 10:31
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil， 
	
	Thanks for your rapid reply. 
	I am confused by your comments, are you suggesting EverythingoverIPoverMPLS-TP? AFAIK, MPLS-TP can carry many kinds of clients, not just IP.In my example, E1overPWoverMPLS-TP, there is no IP layer at all.   
	 
	NH=> Fully understand.  I was giving IP as an *example* of a technology that can support real external applications because it has message/file/stream application adaptation functions in the form of UDP/TCP/RTP.   In the case of E1 that you note (as E1overPWoverMPLS-TP) you have to ask yourself what specific *external* applications does the E1 support here?.....always remembering that *any* networking technology MUST ultimately support some form of *externally sourced* information source else it is not serving any purpose.  So just supporting E1 on its own does not provide this....for example ask yourself how voice or any type of message/file data gets carried by the E1. 
	
	And you don’t answer my question: IP is a top-of-stack network in the case of E1overPWoverIP, why doesn't MPLS-TP be a top-of-stack network in the case of E1overPWoverMPLS-TP? They are at the same position in the stack, and I think E1 is ‘real external stream applications’ 
	 
	NH=> The point here is that *any* network mode/technology (be it cl-ps, co-ps or co-cs) can act as the server for any other mode/technology.  However, not all technologies can support external applications.....to support these the technology must have application adaptation functions for the message/file/stream information sources that are generated in external CPE, eg phone, PC, etc. 
	 
	Most technologies do not have these external application adaptation functions and so the only job they can do is create the topology of other layer networks. 
	 
	So yes we can use IP (cl-ps) to carry SDH VC4 (co-cs) if we want.......probably not a good idea but it is for sure possible.  However, an SDH VC4 network cannot *directly* support either voice or data but an IP network can.....because IP has UDP/TCP/RTP applications adaptations and SDH VC4 does not have these.  Having said that, there is in principle no reason why any mode/technology (even SDH VC4) cannot support external message/file/stream applications......its just that for most technologies these have never been specified because they were only ever intended to provide a 'network builder' transport role. 
	 
	Aside=> If a technology X can support message/file/stream applications directly then here we would most definitely have to consider peer-interworking technology X with both IP (Internet) and PSTN (voice case only).  In all other cases (ie where technology X is not top-of-stack, ie does not have message/file/stream application adaptation functions) there is no need for peer-interworking it with any other technology, including IP (Internet) and PSTN. 

	Your final point ("I think E1 is ‘real external stream applications’" ) is not strictly correct but I can fully understand why you say this.  E1 belongs to the co-cs mode.  When you analyse this (as is done in G.800, which explains why the 3 network modes arise from information/systems theory considerations) you find that in the time dimension the co-cs mode partitions resource (time) up into regular time slices....so this means both the start epoch (an implicit label) and (most crucially) its duration are fixed.   
	 
	Without going into major detail here (I have paper on this I can send you if you want...just ask) what this means is that the co-cs mode is the ultimate 'smoother/shaper' for client traffic......so as you rightly observe this looks like a stream case.  It's not a specific external application however like human voice or video (these must generate real *information* that communicating parties understand) but it for sure has the CBR behaviour of a stream. 
	 
	BTW the reason the co-cs mode has been enduringly successful as a transport network is because it provides *transparency* to all clients (which is exactly the similar behaviour of a stream as you note), ie 
	-    all client bits treated equally (a really key point this, as this means it provides equal 'importance' treatment of the ultimate higher level (and unseen/unknown by the co-cs transport network) message/file/stream applications) 
	-    client bit ordering is preserved 
	-    does not try an infer meaning of client bits nor change them 
	-    ensures the traffic behaviour of client X cannot impact the performance experienced by party Y. 

	regards, Neil 
	
	Regards, 
	Suhui. 
	
<[email-masked]> 

2009-04-29 14:40 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	

	Thanks Shuhui, 
	
	Do not confuse physical interconnect with E-NNI.....I'll come back on this shortly when discussing the bottom-of-stack section layer. 
	
	The first thing to understand is that *all* networks are there to ultimately support one purpose.....and that is to allow communications between parties that are *external* to the networks.  So everything we do in networking is there to ultimately support this objective.  What this means is that the DP of some network (what I call the top-of-stack network) MUST be providing adaptation functions for these external applications.......and these can generically be classified as messages, files and streams. 
	
	We can see that IP is a top-of-stack network as it has UDP/TCP/RTP (for example) adaptations.  ATM was also once (~90s) intended to be a top-of-stack network and it had its own application adaptations in the form of AALs.  At one stage there were 5 of these, but in practice only a couple were really successful because of the generic nature of message/file/stream classification.  The PSTN is also top-of-stack, and its application adaptation was mainly for voice (stream) support. 
	
	Most other networks do not have these application adaptation functions....so they do not directly support applications.  What this means in practice is that these networks (a list which includes PDH, SDH, OTN, Ethernet, MPLS) MUST carry a further layer network above them that is top-of-stack....like IP.  There is no choice in the matter here.  So whilst we might say that an MPLS network is carrying an E1 PW the E1 entity must in turn be carrying some other top-of-stack network (like IP or PSTN), else it is serving no ultimate purpose. 
	
	Now in order to transmit information over geographic distance we must modulate an EM wave on some metallic/optical/radio media....this is the bottom-of-stack section layer.  These are high bit rate transport pipes whose function is to provide transparent (which I have defined previously) transport to whatever client layers networks sit above them....and where, as I noted above, there MUST be a top-of-stack network present as the ultimate layer network client else there is not external party communication possible. 
	
	So when we connect together 2 top-of-stack networks we do so at a section layer which is invariably carrying a very large aggregate of applications.....and of course these applications can be a time varying mix of message/file/stream cases with a set of unknown (to the section layer) importance's (ergo why transparency is an essential requirement in transport networks). 
	
	The real E-NNIs (which considers both DP and CP components....we never usually peer the MP, and we restrict the scope of the CP) exist in the top-of-stack layer network.  The section layer interconnect is a dumb DP pipe...it just shifts bits transparently and maintains their ordering.  There is no concept of CP (or MP) peering on these bottom-of-stack section layer interconnects. 
	Aside=> In some countries these interconnects have to be carefully specified in order to distinguish regulated and unregulated services.....so there are important legal/commercial considerations here, it is not simply a technical issue. 
	
	We can of course create E-NNIs in non top-of-stack layer networks (we can do many things that are not useful).  So lets assume we do this.....and lets assume we choose MPLS since you mention this in the mail below. 
	
	Now how do external parties who wish to communicate interface with this MPLS network?  Can you support all types of message/file/stream applications *directly* into MPLS?  In principle you could if you allowed MPLS to have end system application adaptations such as UDP/TCP/RTP or the like.  But these don't exist today, and in the most usual case the MPLS network will carry an IP layer network because this can support the message/file/stream applications. 
	
	We can go through exactly the same analysis with any network that is not top-of-stack, eg Ethernet.  And when you do this what you realise is that although we can create peer interworking of MPLS (or whatever) this has not really helped since we might as well have just terminated the MPLS network and passed the IP layer across. 
	
	Now the above becomes even more striking in its importance if you consider peer interworking of 2 different non top-of-stack networks....lets pick MPLS and Ethernet because that is what is often mentioned.   
	
	What we have to do now at the E-NNIs between Ethernet and MPLS is go through each DP and CP component and do a 'protocol conversion' exercise where required......and the first problem you will encounter is that there will be lots of functional mismatch.  Moreover if one or both of the networks can support multiple CP types like MPLS can, eg RSVP-TE signalling, LDP signalling, BGP4 'signalling', OSPF routing, IS-IS routing.....and I could list similar for Ethernet.....you are going to have to consider each pairing case in turn.  A lot of work. 
	
	And when you have done all this you ask the question 'what is it that carries the real external message/file/stream applications in the DP here?'.......and now you find no native support for these in MPLS or Ethernet, but what we do find is that both of them are carrying IP because this does support the external applications.  Now at this point we have discovered what is the common thing between MPLS and Ethernet....it is the top-of-stack IP layer network.  And so we ultimately realise we could have save ourselves a load of unnecessary work by simply terminating the MPLS and Ethernet layer network at the interworking point and just passed the IP layer network across. 
	
	Sorry I've had to go through all this yet again (esp for all the folks that have already understood the point) but I do hope its clear now and we can put this issue to bed. 
	
	regards, Neil 

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 29 April 2009 03:22
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil, 
	
	‘it is quite clear from a simple technical analysis that any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties.’ 
	
	I cannot agree this statement. 
	For example, there are two IP networks belonging to two operators, a E1 is transported from A network to B network (e.g. E1overPWoverIP ), IP packet(not E1) pass across form A to B at border node, so there is a E-NNI between these  two IP network. In this case, is IP a top-of-stack network? 
	Now let us replace IP networks by MPLS-TP networks (e.g. E1overPWoverMPL-TP), MPLS-TP network is at same position in the stack as IP network is, why can IP network have E-NNI but MPLS-TP cannot? 
	
	Regard, 
	Suhui 
<[email-masked]> 

2009-04-28 14:43 

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]> 
抄送
[email-masked] 
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	

	

	

	
	
	regards, Neil

---

From: [email-masked]
Date: Tue, 5 May 2009 11:00:37 +0800

Hi Neil，
In my example，There are two different parties of SDH network which belong 
to two operators, there is only one single party of Eth network which 
belong to one customer. The Operators don't know what kind of client is 
carried by Eth. In this case, I think using SDH ENNI to connect two SDH 
network is better than passing Eth across, and as I know, SDH ENNI are 
already widely used.

Regards,
Suhui.

<[email-masked]> 
2009-05-04 17:48

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

Thanks Suihui,
 
The crucial factor here is who owns which layer networks are whether we 
are dealing with a private or public top-of-stack network case....I will 
come back on this point shortly.
 
As a general onservation however, it is not a trivial technical or 
commercial matter to interwork as peers any mode/technology network 
between different operating parties.  One has to consider all DP/CP 
(usually not MP) components.  If they are not identically the same in all 
DP/CP components one has protocol conversion issues to deal with.  And 
don't forget you now 'lock' the 2 (or more) parties involved wrt how 
*both* their networks and commercial services can evolve...and this will 
also have to consider the legal/regulatory framework in force in that 
country.  This is not a smart idea at all when the networks are not 
top-of-stack and have different party ownership.
 
In the case you show below then a critical issue to understand first is 
who owns which layer networks?  Are there 2 different parties wrt SDH VC4 
or a single party?  Are there 2 different parties wrt Ethernet or a single 
party?  And what kind of network lies above Ethernet?...is it a private or 
public network case?
 
If there are different parties also at the Ethernet layer then my argument 
simply recurses upwards, ie one does *not* pass the Ethernet layer network 
transparently here but one terminates it and either:
-    passes the next layer network up transparently *irrespective of 
whether it is top-of-stack or not *  IF it  is owned by a single party
-    if the next network layer network up is top-of-stack AND it is a 
private network AND there is a bilateral peering agreement between the 
parties AND if there are no adverse regulatory considerations then one 
could peer interwork this case (but caveat emptor would be my advice);
-    if the next network layer network up is top-of-stack AND it is a 
public network (eg PSTN, Internet) then one will most definitel peer 
interwork this case
 
BTW In the case other Ethernet over SDH VC4 there will also be GFP 
adaptation.
 
regards, Neil
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport 
path requirements)

Hi Neil, 

Reguard, 
Suhui. 

(part A)                                (part B) 

<[email-masked]> 
2009-04-30 14:28 

收件人
<[email-masked]> 
抄送

Thanks Suhui 

Hi Neil, 

  

  

 
Neil Harrison

Regards, 
Suhui. 

<[email-masked]> 
2009-04-29 18:21 

收件人
<[email-masked]> 
抄送

Hi Neil， 

 

 

 

regards, Neil 

Regards, 
Suhui. 
<[email-masked]> 
2009-04-29 14:40 

收件人
<[email-masked]> 
抄送

Thanks Shuhui, 

regards, Neil 

Hi Neil, 

Regard, 
Suhui 
<[email-masked]> 

收件人

regards, Neil

---

From: <[email-masked]>
Date: Tue, 5 May 2009 21:48:25 +0100

Thanks and sorry for late reply Suhui.   
-    Are you sure what you mean here is an E-NNI and not simply a bit pipe DP interconnect (noting that the latter must always be present and lies below the binary VC4 path signal at the physical section layer where the EM wave is modulated)?
-    If it is an E-NNI then what assumptions are being made here wrt CP, MP and DP components , eg signalling protocol used, routing protocol used, DP/CP addressing, etc?
-    How is the E-NNI specification different from the I-NNI specification....indeed which E-NNI standard is being used here?
-    does the client (and specific service) of the SDH VC4 have to be specified or not?....if it does what restrictions are in place, eg regulatory assumptions?
 
I am very clear in my own mind that what constitutes an E-NNI is more that simply a transparent DP bit pipe.  A transparent DP bit pipe must always exist (at the bottom of stack) in all networking cases simply to transfer information (irrespective of what that information ultimately relates to in the higher layer networks that do have to peer interwork) across geographic distance by the modulation of an EM wave in some metallic/optical/radio media.....but this DP bit pipe is for sure not an E-NNI, but I can understand why some folks may mistakenly make that assumption.
 
I suspect we probably should leave this topic now and agree to disagree.   Hope that is OK.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 05 May 2009 04:01
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: RE: About ENNI([mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements))

	Hi Neil， 
	In my example，There are two different parties of SDH network which belong to two operators, there is only one single party of Eth network which belong to one customer. The Operators don't know what kind of client is carried by Eth. In this case, I think using SDH ENNI to connect two SDH network is better than passing Eth across, and as I know, SDH ENNI are already widely used. 
	
	Regards, 
	Suhui. 

	
<[email-masked]> 

2009-05-04 17:48 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Thanks Suihui, 

	  

	  
	regards, Neil 

	Hi Neil, 

	Reguard, 
	Suhui. 
	
	(part A)                                (part B) 

<[email-masked]> 

2009-04-30 14:28 

收件人
<[email-masked]> 
抄送

	

	Thanks Suhui 

	Hi Neil, 

	 

	 

	Neil Harrison

	Regards, 
	Suhui. 

<[email-masked]> 

2009-04-29 18:21 

收件人
<[email-masked]> 
抄送

	

	Hi Neil， 

	

	

	

	regards, Neil 
	
	Regards, 
	Suhui. 
<[email-masked]> 

2009-04-29 14:40 

收件人
<[email-masked]> 
抄送

	

	
	Thanks Shuhui, 

	

	

	

	

	
	regards, Neil 

	Hi Neil, 

	
	Regard, 
	Suhui 
<[email-masked]> 

2009-04-28 14:43 

收件人

	

	

	

	
	regards, Neil