Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

From: [email-masked]
Date: Mon, 2 Aug 2010 10:38:08 +0800

Maarten,
thank you for clarify it in detail, but I can't agree your opinions;
 maybe bit error, congestion in the link or in the below server layer 
only affect part of LSP or service layer paths in the link section or 
server layer
 for a special time, IMO, if the failure ,eg, bit error, congestion 
continuce to 
exist in the link or server layer for a long time, it must affect all 
other LSP or
service layer paths at last. so SD indication still be generated in all 
LSP or service layer
even if there is no failure in some LSP or service layer paths in the link 
or server layer 
at the time.
do you think so?

in addtion, For E-LSP , eg. there is 8 tpyes of prioriy services in the 
LSP. 
if one or more types of services have detect SD defect, whether to need 
all services
 in the LSP to switch into protection path . or only some types of service 
which have 
 detected SD Defect will switch into protection path.while other types of 
service which have not
 detected SD Defect will continue to be transported and carried by the LSP 
?
 I wish you can provide an obvious answer. thank you

  best regards
  liu

Maarten Vissers <[email-masked]> 
2010-07-30 19:44

收件人
[email-masked], 'Rafi Ram' <[email-masked]>
抄送
[email-masked], [email-masked], [email-masked]
主题
RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Liu,
 
SD defects are based on a packet loss ratio (PLR), i.e. the ratio of
transmitted packets and lost packets.
The first packet loss is detected by the Section MEP and is computed over
all non-drop eligible packets with priority X and on the link/section.
The second packet loss is detected by a Transport Path MEP and is computed
over all non-drop eligible packets with priority X and on the transport 
path
connection (e.g. transport-LSP, transport path SPME LSP).
The third packet loss is detected by a Transport Service MEP and is 
computed
over all non-drop eligible packets with priority X and on the transport
service connection (e.g. PW, service-LSP, transport service SPME LSP).
 
Assume that a Section carries 100 transport-LSPs and that each 
transport-LSP
carries 50 service-LSPs/PWs/HVPLSs then the Section carries 5000 service
LSPs/PWs/HVPLSs.
 
Your question below translates in this example into the question if bit
errors in the physical media will lead to packet loss in one or more of 
the
100 transport-LSPs and in one or more of the 5000 service-LSPs, PWs and
HVPLS instances?
 
Individual bit errors (after FEC correction) will only hit one packet and
thus one of the 100 transport-LSPs and one of the 5000
service-LSPs/PWs/HVPLSs; which one of those 100 or 5000 instances is
unknown.

The EB counting is performed per 1-second period, and ODU dDEG is detected
(and ODU SD is triggered) when M (default 7) seconds have more then 15% 
EBs
(refer to G.8201 and G.798).

15% EBs implies that there are one or more bit errors (after FEC) in every
7th ODU frame. An ODU frame carries the MPLS-TP packets in its OPU 
payload,
which contains 15232 bytes. Assuming an average MPLS-TP packet length of 
256
bytes and GFP-F encapsulation with GFP FCS, an OPU frame will contain up 
to
56 MPLS-TP packets and 7 OPU frames will contain up to about 400 packets. 
An
ODU SD condition would then imply that every 400 packets one or more will
contain bit errors and will thus be discarded when the ODU is terminated 
and
the MPLS-TP packets are extracted. 

The question is if you would like to initiate protection switching on 
either
100 transport-LSPs or 5000 service-LSPs/Pws/HVPLSs when there is >=0.25%
committed traffic packet loss at the section layer?

Regards,
Maarten 
PS. Please be aware that for Ethernet frame loss counting is now 
implemented
and introduced into the networks; note that p2p VLANs are like E-LSPs.
Draft-bhh intents to reuse those implementations and combine them with
MPLS-TP OAM headers. I.e. if it works for Ethernet VLANs, it should work
also for MPLS-TP. Also some T-MPLS designs already support packet loss
counting on the basis of these Ethernet designs. Would MPLS-TP be so much
worse/different then Ethernet and T-MPLS?

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 29 juli 2010 8:26
To: Rafi Ram
Cc: [email-masked]; Maarten Vissers; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

hi,all 
it is unclear for me whether sd of server layer eg. bit error , congestion
etc, will lead to SD condition in the lsp layer? 
if the answer is yes, we may make use of SD detection of server layer to
indicate SD defect of LSP Layer; 
if the answer is no, we may detect SD of LSP layer by LM or DM function, 
IMO, the method MAY be very hard and diffcult to detect SD by LM or DM
function for E-LSP. 

can i miss something important ? 
 
best regards 
liu

"Rafi Ram" <[email-masked]> 
发件人:  [email-masked] 

2010-07-29 02:57 

--------------------------------------------------------
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, 2 Aug 2010 08:26:02 +0100

Liu..please see in-line:

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: 02 August 2010 03:38
	To: Maarten Vissers
	Cc: 'Rafi Ram'; [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

	Maarten, 
	thank you for clarify it in detail, but I can't agree your
opinions; 
	 maybe bit error, congestion in the link or in the below server
layer 
	only affect part of LSP or service layer paths in the link
section or server layer 
	 for a special time, IMO, if the failure ,eg, bit error,
congestion continuce to 
	exist in the link or server layer for a long time, it must
affect all other LSP or 
	service layer paths at last. so SD indication still be generated
in all LSP or service layer 
	even if there is no failure in some LSP or service layer paths
in the link or server layer 
	at the time. 
	do you think so? 
	
	in addtion, For E-LSP , eg. there is 8 tpyes of prioriy services
in the LSP. 
	if one or more types of services have detect SD defect, whether
to need all services 
	 in the LSP to switch into protection path . or only some types
of service which have 
	 detected SD Defect will switch into protection path.while other
types of service which have not 
	 detected SD Defect will continue to be transported and carried
by the LSP ? 
	 I wish you can provide an obvious answer. thank you 
 
NH=> Just because something is possible in a given network mode does not
make it sensible.  We can often create an illusion of something useful
when in fact all we are doing in generating unnecessary complexity and
costs.  I can list lots of examples of this.....especially in the co-ps
mode as this has the richest set of possibilities for generating
unnecessary complexity/cost (one can only truly appreciate this IMO if
one understands how each of the 3 network modes arise from resource
partitioning and labelling considerations).  
	 
In the case in question here we are talking about the old QoS illusion
of something useful...here having lots of traffic classes in a single
connection (one assumes one does at least respect the single source
requirement of a connection, else nothing useful is possible wrt
resource management).

If one understands how real networks must be designed/operated one
notices these factors:
	 
-	Any application can assume any (survivability) importance
requirement for a fixed (QoS/delay) urgency requirement.  This means
that under network stress that creates a resource shortfall (eg failures
or congestion) it is important to be clear which traffic survives and
which gets discarded...and we can't make any meaningful judgement on
this just on the basis of QoS markings or the application type.....but
in a transport network, where the critical service behaviour is
transparency, we had better not even try anyway! (see further remarks on
this transparency issue later).

-	For networks to be practically viable they will operate at a
relatively low load for most of the time.  Some factors that determine
this are:
* traffic forecast uncertainty at the start of a planning cycle;
* daily peak/mean traffic load fluctuations;
* the fact that the server layer networks (which create the link
connections in the client layer topology) come in increasingly larger
bandwidth increments at each planning cycle build epoch;
* resilience requires, as a rule of thumb, at least 30% spare capacity
in the layer network.
....and of course the network needs to provide an acceptable level of
performance to customers *at the end of the current planning
cycle*...ergo for most of the working life (>>99% of time) the network
load is well to the LHS of the congestion knee and here all QoS classes
will look alike.

It is also worth noting that when the network breaks we transition very
quickly to the RHS of the congestion knee, and here the critical
performance issue is nothing to do with application/QoS (==delay)
requirements but all about survivability requirements......in which, as
I noted above, any application can assume any value...so survivability
importance has nothing to do with application type or QoS classes.

2 very important points are also latent in what I have just said above:

-	when we are providing a transport service we MUST NOT be
snooping the client traffic symbols and trying to infer their meaning
(eg trying to figure out the real TOS layer network message/file/stream
application which may be >= 1 layer network higher)....so we cannot, and
indeed must not try to, appeal to this flawed notion anyway;

-	one must never try and optimise network design around the
congestion knee as the behaviour here is highly non-linear....and since
in a practically viable network we must be operating for >>99% of time
well to the left of the congestion knee where all traffic classes must
look alike, then it ought to be quite clear that there would be little
practical merit is providing all the traffic classes 'just because we
can' anyway.

One will also create horrible (combinatorial) complexities wrt things
like defining entry/exit criteria for SD and unavailability across
multiple traffic classes in a single connection.

So, these are some of the reasons why it is not a good idea to have
multiple traffic classes in a single connection.  And in the case of a
transport network, such as MPLS-TP which is supposed to be providing a
transparent client service, one MUST only have a single traffic class
and all client symbols must be treated equally (wrt information content)
and their ordering preserved.

Aside=> However, as I have pointed out previously MPLS-TP cannot claim
to be a transport network whilst it still has PWs and LSP sublayering.
This also relates to the point above about not understanding/respecting
the critical transparency requirement of a true transport network.

regards, Neil

	  best regards 
	  liu 
<NH snipped to end>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Aug 2010 09:34:21 +0200

Liu,
 
I have no data that describes the relationship between ODU errored block
rate and loss of committed packets in LSPs/PWs. I only know that we should
not introduce an physical layer SD detection propagation OAM mechanism as
long as we do not have any  indication that an e.g. ODU SES based SD
condition represents a minimum committed packet loss in each LSP and PW. It
should be possible to set up a test case in which you carry e.g. 5000
service-LSPs/PWs in e.gt. 100 transport-LSPs in one ODU/OTU and then
increase the error rate and measure the ODU EB rate versus the
transport-LSP, service-LSP/PW committed packet loss rate per priority.

In a packet transport network typically 3 to 4 priorities are in use and
most services (service-LSps, PWs) have just one priority. Some services have
more then one (e.g. 2) priorities. Transport-LSPs will have all 3/4
priorities. E-LSPs carrying 2 or more priorities will have to measure SD
either for one priority (as is today for Ethernet), or for multiple
priorities. LSP/PW protection will have to protect all traffic inside the
service-LSP/PW, not just a subset of the traffic flows. The transport
customers consider their transport services as a single entity, not multiple
individual entities. 

If you want to protect a subset of traffic, then you can do this for
transport-LSPs. For this case you can protect the subset of service-LSPs/PWs
carried inside a transport-LSP that are degraded. Use 1:1 CL-SNCG/I
protection of the service-LSPs/PWs/HVPLSs in this case.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 4:38
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]; 'Rafi Ram'
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten, 
thank you for clarify it in detail, but I can't agree your opinions; 
 maybe bit error, congestion in the link or in the below server layer 
only affect part of LSP or service layer paths in the link section or server
layer 
 for a special time, IMO, if the failure ,eg, bit error, congestion
continuce to 
exist in the link or server layer for a long time, it must affect all other
LSP or 
service layer paths at last. so SD indication still be generated in all LSP
or service layer 
even if there is no failure in some LSP or service layer paths in the link
or server layer 
at the time. 
do you think so? 

in addtion, For E-LSP , eg. there is 8 tpyes of prioriy services in the LSP.

if one or more types of services have detect SD defect, whether to need all
services 
 in the LSP to switch into protection path . or only some types of service
which have 
 detected SD Defect will switch into protection path.while other types of
service which have not 
 detected SD Defect will continue to be transported and carried by the LSP ?

  best regards 
  liu 

2010-07-30 19:44 

收件人

Liu,

over all non-drop eligible packets with priority X and on the transport path
The third packet loss is detected by a Transport Service MEP and is computed

Assume that a Section carries 100 transport-LSPs and that each transport-LSP
carries 50 service-LSPs/PWs/HVPLSs then the Section carries 5000 service
LSPs/PWs/HVPLSs.

Your question below translates in this example into the question if bit
errors in the physical media will lead to packet loss in one or more of the
100 transport-LSPs and in one or more of the 5000 service-LSPs, PWs and
HVPLS instances?

The EB counting is performed per 1-second period, and ODU dDEG is detected
(and ODU SD is triggered) when M (default 7) seconds have more then 15% EBs
(refer to G.8201 and G.798).

15% EBs implies that there are one or more bit errors (after FEC) in every
7th ODU frame. An ODU frame carries the MPLS-TP packets in its OPU payload,
which contains 15232 bytes. Assuming an average MPLS-TP packet length of 256
bytes and GFP-F encapsulation with GFP FCS, an OPU frame will contain up to
56 MPLS-TP packets and 7 OPU frames will contain up to about 400 packets. An
ODU SD condition would then imply that every 400 packets one or more will
contain bit errors and will thus be discarded when the ODU is terminated and
the MPLS-TP packets are extracted. 

The question is if you would like to initiate protection switching on either
100 transport-LSPs or 5000 service-LSPs/Pws/HVPLSs when there is >=0.25%
committed traffic packet loss at the section layer?

Regards,
Maarten 
PS. Please be aware that for Ethernet frame loss counting is now implemented

hi,all 

best regards 
liu

---

From: [email-masked]
Date: Mon, 2 Aug 2010 16:04:46 +0800

Maarten,
thank you , I already understand what you said. 
each T-LSP would be regarded as a single entity, but SD Detection would 
be based on one priority to be detected and measured for E-LSP
is my understanding true?

best regards
liu

2010-08-02 15:34

收件人
[email-masked]
抄送
[email-masked]
主题

Liu,
 
condition represents a minimum committed packet loss in each LSP and PW. 
It

In a packet transport network typically 3 to 4 priorities are in use and
most services (service-LSps, PWs) have just one priority. Some services 
have
more then one (e.g. 2) priorities. Transport-LSPs will have all 3/4
priorities. E-LSPs carrying 2 or more priorities will have to measure SD
either for one priority (as is today for Ethernet), or for multiple
priorities. LSP/PW protection will have to protect all traffic inside the
service-LSP/PW, not just a subset of the traffic flows. The transport
customers consider their transport services as a single entity, not 
multiple
individual entities. 

If you want to protect a subset of traffic, then you can do this for
transport-LSPs. For this case you can protect the subset of 
service-LSPs/PWs
carried inside a transport-LSP that are degraded. Use 1:1 CL-SNCG/I
protection of the service-LSPs/PWs/HVPLSs in this case.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 4:38
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]; 'Rafi 
Ram'
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten, 
server
other
LSP

all

  best regards 
  liu 

2010-07-30 19:44 

收件人
                 [email-masked], 'Rafi Ram' <[email-masked]> 
抄送
                 [email-masked], [email-masked], 
[email-masked] 
主题
                 RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Liu,

Regards,
Maarten 

hi,all 

best regards 
liu

---

From: [email-masked]
Date: Mon, 2 Aug 2010 16:24:52 +0800

Neil
thank you for clarify it in detail. I agree part of your opinions.
for transport network, transparent is an important characteristic for all 
kinds
of client service. but I think that it is necessary to provide multiple 
traffic classes in a single connection.
if so, it may provide all kinds of service with different QOS in a single 
connection
or else, there is the same priority in a single connection, how to ensure 
the quality of important and more priority service
in a single connection.

can i miss something important? 

best regards
liu 

<[email-masked]> 
2010-08-02 15:26

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Liu..please see in-line:

                 From: [email-masked] 
[mailto:[email-masked]]
On Behalf Of [email-masked]
                 Sent: 02 August 2010 03:38
                 To: Maarten Vissers
                 Cc: 'Rafi Ram'; [email-masked]; 
[email-masked]
                 Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

                 Maarten, 
                 thank you for clarify it in detail, but I can't agree 
your
opinions; 
                  maybe bit error, congestion in the link or in the below 
server
layer 
                 only affect part of LSP or service layer paths in the 
link
section or server layer 
                  for a special time, IMO, if the failure ,eg, bit error,
congestion continuce to 
                 exist in the link or server layer for a long time, it 
must
affect all other LSP or 
                 service layer paths at last. so SD indication still be 
generated
in all LSP or service layer 
                 even if there is no failure in some LSP or service layer 
paths
in the link or server layer 
                 at the time. 
                 do you think so? 
 
                 in addtion, For E-LSP , eg. there is 8 tpyes of prioriy 
services
in the LSP. 
                 if one or more types of services have detect SD defect, 
whether
to need all services 
                  in the LSP to switch into protection path . or only some 
types
of service which have 
                  detected SD Defect will switch into protection 
path.while other
types of service which have not 
                  detected SD Defect will continue to be transported and 
carried
by the LSP ? 
                  I wish you can provide an obvious answer. thank you 

 

-                For networks to be practically viable they will operate 
at a

regards, Neil

                   best regards 
                   liu 
<NH snipped to end>

---

From: <[email-masked]>
Date: Mon, 2 Aug 2010 10:05:48 +0100

Why was this not necessary in an SDH VC4 layer network say or some OTN layer network?
 
As I said, 'just because you can' does not mean it is *really* useful.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 02 August 2010 09:25
	To: Harrison,N,Neil,DKQ7 R
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

	Neil 
	thank you for clarify it in detail. I agree part of your opinions. 
	for transport network, transparent is an important characteristic for all kinds 
	of client service. but I think that it is necessary to provide multiple traffic classes in a single connection. 
	if so, it may provide all kinds of service with different QOS in a single connection 
	or else, there is the same priority in a single connection, how to ensure the quality of important and more priority service 
	in a single connection. 

	best regards 
	liu 

<[email-masked]> 

2010-08-02 15:26 

收件人

	Liu..please see in-line:

	
	                Maarten, 

	                 

	

	

	

	regards, Neil

	                  best regards 
	                  liu 
	<NH snipped to end>

---

From: [email-masked]
Date: Mon, 2 Aug 2010 19:09:45 +0800

Neil
In my mind, like SDH or OTN Layer network, which is co-cs network and 
ensure 
the quality of each service in SDH or OTN layer .
while mpls-tp or mpls is co-ps network, which can't ensure the quality of 
each
service . some service packets will be lost and delayed because of being 
short of
bandwidth resource. so it is necessary to provide multiple traffic classes 
in a single connection,
so that the real-time service which will have more priority , would be 
ensured to transport very
rapidly and well.

best regards
liu

<[email-masked]> 
2010-08-02 17:05

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Why was this not necessary in an SDH VC4 layer network say or some OTN 
layer network?

regards, Neil

From: [email-masked] [mailto:[email-masked]] 
Sent: 02 August 2010 09:25
To: Harrison,N,Neil,DKQ7 R
Cc: [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Neil 

best regards 
liu 

<[email-masked]> 
2010-08-02 15:26 

收件人

Liu..please see in-line:

                Maarten, 
 
                 detected SD Defect will switch into protection path.while 

 
-                 Any application can assume any (survivability) 
importance

-                 one must never try and optimise network design around 
the

regards, Neil

                  best regards 
                  liu 
<NH snipped to end>

--------------------------------------------------------
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: Maarten Vissers <[email-masked]>
Date: Mon, 02 Aug 2010 14:45:56 +0200

Liu,
 
the SD condition in a TP-E-LSP with 2 or more priorities with committed rate
could be determined either 
1) by monitoring the committed rate packet loss of one of these priorities
(SD = dDEG(priority #i)) , 
or 
2) by monitoring the committed rate packet loss of each of these priorities
(SD = dDEG(priority #i) or dDEG(priority #j) or .. ). 
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 10:05
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten, 

best regards 
liu

2010-08-02 15:34 

收件人
[email-masked] 

抄送
[email-masked] 

主题

Liu,

Regards,
Maarten

Maarten, 

 best regards 
 liu 

2010-07-30 19:44 

收件人

主题

Liu,

Regards,
Maarten 

hi,all 

best regards 
liu

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 12:53:49 -0400

In message <[email-masked]>
Maarten Vissers writes:
>  
> Liu,
>  
> I have no data that describes the relationship between ODU errored
> block rate and loss of committed packets in LSPs/PWs. I only know that
> we should not introduce an physical layer SD detection propagation OAM
> mechanism as long as we do not have any indication that an e.g. ODU
> SES based SD condition represents a minimum committed packet loss in
> each LSP and PW. It should be possible to set up a test case in which
> you carry e.g. 5000 service-LSPs/PWs in e.gt. 100 transport-LSPs in
> one ODU/OTU and then increase the error rate and measure the ODU EB
> rate versus the transport-LSP, service-LSP/PW committed packet loss
> rate per priority.
>  
> In a packet transport network typically 3 to 4 priorities are in use
> and most services (service-LSps, PWs) have just one priority. Some
> services have more then one (e.g. 2) priorities. Transport-LSPs will
> have all 3/4 priorities. E-LSPs carrying 2 or more priorities will
> have to measure SD either for one priority (as is today for Ethernet),
> or for multiple priorities. LSP/PW protection will have to protect all
> traffic inside the service-LSP/PW, not just a subset of the traffic
> flows. The transport customers consider their transport services as a
> single entity, not multiple individual entities.
>  
> service-LSPs/PWs carried inside a transport-LSP that are degraded. Use
> 1:1 CL-SNCG/I protection of the service-LSPs/PWs/HVPLSs in this case.
>  
> Regards,
> Maarten

Maarten,

I've changed the subject since this is a thread that is somewhat
tangential to the main topic.

Current practices in MPLS networks is quite different than in
transport networks and these MPLS practices make good business sense
as I will explain.

Typically one LSP between any two edges of the tier (ie: edges of the
core) will carry most or all services but with different TC markings.
Some services have extremely low capacity requirements but are loss
intolerant and have limited (but some) jitter tolerance.  One such
service is VOIP.  Other services have somewhat larger capacity
requirements and have SLA that are mostly based on loss, but may be
based on delay as well.  These include all VPN services including
legacy (ATM, FR, low speed TDM, SONET), layer-2 Ethernet (inter-metro
Ethernet carried over PW), and layer-3 VPN.  The capacity needed for
these services combined is dwarfed by the capacity required for
business and consumer Internet.

When FRR protection is used with zero bandwidth facility backup
reservations, the preferred traffic is recovered within 50 msec.  A
reroute of the working path will occur within a few seconds providing
protection against a second fault.  This works with the multiple fault
(backhoe, train wreck, bridge collapse, earhquake, flood, huricane)
that doesn't snap all of the cables at once, or disable multiple sites
at once (for example in a flood or hurricane, grid and then generator
power may be lost hours apart in each site but not restored as some
sites for days).

Typically these networks are provisioned for zero congestion after a
single fault (more common than multiple faults).  If a multiple fault
occurs, then congestion is only experienced by business and consumer
Internet, and if business Internet is paying more it may experience
less congestion that consumer Internet (ie: AF service for business
Internet, where AFx3 is same priority as BE, but AFx[12] are
preferred).

The reason this makes business sense is that the provisioning can
reflect the average capacity needed for preferred service, yet due to
the dominance of BE traffic (consumer Internet and to a lesser extent
business Internet) the high margin preferred services have true
bandwidth guarentees (at the expense of BE if they were ever to use
it).  For layer-2 Ethernet VPN and IP VPN, the cost of carrying these
service instances can be as little as 10% of the cost of dedicated
capacity such as would be required in traditional transport,
particularly TDM (including ODUflex).

These business drivers count for much more than the noise you or I add
to this mailing list.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Aug 2010 14:18:23 +0200

Curtis, 

See inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 18:54
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: current practices (was Re: [mpls-tp] New ID
draft-rkhd-mpls-tp-sd-00)

<..>

I've changed the subject since this is a thread that is somewhat tangential
to the main topic.

Current practices in MPLS networks is quite different than in transport
networks and these MPLS practices make good business sense as I will
explain.

[maarten] Same in a packet transport network.

Some services have extremely low capacity requirements but are loss
intolerant and have limited (but some) jitter tolerance.  One such service
is VOIP.  Other services have somewhat larger capacity requirements and have
SLA that are mostly based on loss, but may be based on delay as well.  These
include all VPN services including legacy (ATM, FR, low speed TDM, SONET),
layer-2 Ethernet (inter-metro Ethernet carried over PW), and layer-3 VPN.
The capacity needed for these services combined is dwarfed by the capacity
required for business and consumer Internet.

[maarten] I have same understanding.

When FRR protection is used with zero bandwidth facility backup
reservations, the preferred traffic is recovered within 50 msec.  A reroute
of the working path will occur within a few seconds providing protection
against a second fault.  This works with the multiple fault (backhoe, train
wreck, bridge collapse, earhquake, flood, huricane) that doesn't snap all of
the cables at once, or disable multiple sites at once (for example in a
flood or hurricane, grid and then generator power may be lost hours apart in
each site but not restored as some sites for days).

[maarten] MPLS-TP is extending protection set beyond FRR, introducing PW,
service-LSP and transport-LSP protection. My understanding is that just FRR
support is not enough. If MPLS-TP is operated with a control plane, then it
will also be an option to reroute the failed working path, to protect the
protection path against a second fault.

Typically these networks are provisioned for zero congestion after a single
fault (more common than multiple faults).  

[maarten] If we have the same design principle for MPLS-TP netowrks, then
this implies that the links passed through by the protection path had
suffient resources unused by preferred traffic when traffic is forwarded via
working path. There will thus not be any preferred traffic congestion
occuring when traffic is protected, and forwarded over protection path, as
long as working and protection paths are disjoint. Broadcast bridge will as
such not cause any congestion problem. This reconfirms the starting point
underneath the broadcast bridge solution choice; thanks.

If a multiple fault occurs, then congestion is only experienced by business
and consumer Internet, and if business Internet is paying more it may
experience less congestion that consumer Internet (ie: AF service for
business Internet, where AFx3 is same priority as BE, but AFx[12] are
preferred).

The reason this makes business sense is that the provisioning can reflect
the average capacity needed for preferred service, yet due to the dominance
of BE traffic (consumer Internet and to a lesser extent business Internet)
the high margin preferred services have true bandwidth guarentees (at the
expense of BE if they were ever to use it).  

[maarten] For a long time I have been considering the TC marking as the 4th
survivability control type, similar to your description. 

[maarten] From your description above I get the understanding that
congestion of the preferred traffic is highly unlikely. Is there a guarantee
that congestion of the preferred traffic will **never** occur? 
Note that a misconnection is also unlikely in a transport network, but there
is **no guarantee** that it never occurs... And thus we are required to
check for misconnections.

[maarten] If congestion of preferred traffic never occurs, then SD based on
detection of packet loss or preferred traffic represents the packets losts
due to bit errors on the media. No need to develop any other OAM tool from
this perspective.

[maarten] If congestion of preferred traffic could however in rare cases
occur (i.e. no guarantee that it will never occur), protection will restore
the service performance if SD is detected on the basis of packet loss.

[maarten] Broadcast bridge makes use of the p2mp connection capability that
MPLS-TP nodes have to support. P2mp capabilities in packet technologies
(MPLS(-TP), Ethernet) are not as simple as similar capabilities in circuit
technologies (PDH,SDH,OTN). If reuse of the p2mp technique for protection
switching is too much of a problem for MPLS-TP nodes, then SD condition
definition may have to be changed, and e.g. could be based on synthetic
packet loss detection; i.e. detection of synthetic packet loss measurement
(SPLM) OAM packets. With such SPLM OAM based SD condition it is possible to
deploy a "selector bridge".

For layer-2 Ethernet VPN and IP VPN, the cost of carrying these service
instances can be as little as 10% of the cost of dedicated capacity such as
would be required in traditional transport, particularly TDM (including
ODUflex).

[maarten] It will be cost effective to use an ODUflex when a customer
requires the support of e.g. a 2G Ethernet Private LAN service; i.e. ODUflex
would be used for private services above 1G and then replaces MPLS-TP PW. 
It will also be cost effective to use ODUflex as a transport-LSP replacement
and carry multiple Ethernet Virtual Private Line/Tree/LAN services in one
e.g. 3.75G ODUflex between Ethernet switching points in the network; i.e.
ODUflex would be used when transport-LSP bandwidth >1G.

These business drivers count for much more than the noise you or I add to
this mailing list.

[maarten] :-)

Regards,
Maarten

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 10:16:20 -0400

In message <[email-masked]>
Maarten Vissers writes:
-----8<----- snip (for brevity, just commenting on one point)
> check for misconnections.

We seem to be in agreement on current practice but you asked this
question.  If the preferred traffic in the network core is well under
5% of total traffic as many providers which support a healthy amount
of consumer and business Internet service indicate, then for equal
capacity links it would take an outage of 19 out of a cutset of 20 to
not partition the network but cause congestion for preferred traffic.
Since most core networks seldom have cutsets of more than 4-5 that are
likely to partition, while there is no *guarantee*, the probability of
a complete partition is higher than that of congestion for preferred
traffic.

In practice, the major disasters in the US have created few if any
partitions in core networks, with only localized islands of
connectivity only forming, mostly within metros, more rarely in an
aggregation tier.  Use of layer-2 protection rather than a control
plane has been a major contributor to formations of islands in the
metro where connectivity would have otherwise been possible.

This must all be factored into the provider's business plan.  More
redundancy costs more but penalties result from SLA violations and
severe violations (hours or days of outage) causes customers to go to
other providers.

> due to bit errors on the media. No need to develop any other OAM tool from

You seem to be getting it.  Using OAM based on congestion would move
the entire LSP and it would have a negative impact on preferred
traffic.  The protection for one link is the working for another.  The
N links in a cutset generally protect each other, so sending traffic
twice when congestion is detected would only turn slight congestion
into severe congestion.

> the service performance if SD is detected on the basis of packet loss.

Like I said, this is factored into the business plan.  If a customer's
town or city is under water and has no power (or drinking water, etc),
they tend not to complain that their VPN was down during part of that
time (unless they provide emergency services and need a communications
channel for more than short range radio is able to provide).  If they
are in an unaffected area, they like to see their services remain up,
particularly if a competing provider remained up.

> deploy a "selector bridge".

It is still a bad idea.  I don't buy the argument that P2MP is better
and that is the reason we can ignore the inefficiency of this method.

> ODUflex would be used when transport-LSP bandwidth >1G.

We will see about that.  We have done fairly extensive analysis of how
various technologies map into provider capital costs and our analysis
does not agree with your assertion.  We have also tried to gauge
provider preference on packet vs ODUflex through discussions with
customers.  However this is enough off topic that we should not
discuss it further.

> These business drivers count for much more than the noise you or I add to

Which technology is gaining market share, packets and MPLS or TDM?  :-)

Regards,

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Aug 2010 18:31:57 +0200

Curtis,

If only 5% of the traffic is preferred (i.e. committed) traffic, then
congestion of this traffic will be highly unlikely and I agree with you.

I have always been assuming that in a packet transport network 20-30% of
traffic would be preferred/committed traffic and that some links may be
overbooked on purpose or accidently. Congestion probability would for such
case be non-zero. If we can assume for protection that there is never more
then 5% preferred/committed traffic in a packet network, then life will be
simple :-). Packet loss measurement in an LSP or PW will be representing
packets lost due to bit errors.

This all does not take away the issue with respect to protecting an
individual PW, service-LSP or transport-LSP on the basis of a SD condition
(caused by bit errors in physical media). As long as SD is measured on the
basis of measuring the actual preferred/committed traffic, then SD condition
clears when traffic is removed from working; i.e. zero packets transmitted,
zero received ==> no loss ==> clear SD ==> revert to working ==> detect
packet loss on working ==> declare SD on working again ==> switch ==> etc.

In the draft-ietf-mpls-tp-survive-fwk document the following is described:
   o  Signal degradation - notification from OAM performance monitoring
      indicating degradation in the working entity may also be used as a
      trigger for protection switching.  In the event of degradation,
      switching to the recovery entity is necessary only if the recovery
      entity can guarantee better conditions.  Degradation can be
      measured by proactively activating MPLS-TP OAM packet loss
      measurement or delay measurement.

Under an SD condition on working entity, the framework document describes
that traffic is switched to protection entity. This would clear the SD
condition on working, and we get oscillation.

Draft-ietf-mpls-tp-loss-delay specifies
"1.1.1.  Requirements for Packet Loss Measurement
   The MPLS-TP OAM toolset must provide a function to enable the
   quantification of packet loss ratio over a PW, LSP or Section.
   The loss of a packet is defined in [RFC2680] (Section 2.4).  This
   definition is used here.
   Packet loss ratio is defined here to be the ratio of the number of
   user packets lost to the total number of user packets sent during a
   defined time interval."

Packet loss ratio is determined using user packets, and switching those
packets away from working entity to protection entity will clear the SD
condition. I.e. we get oscillation.

The specifications in the survivability framework and loss detection
documents result in oscillations (W->P->W->P->W->etc) when a packet loss
based SD condition is detected on working entity. This oscillation can be
prevented if one of the following changes is applied:
1) use of 1:1 broadcast bridge instead of 1:1 selector bridge
2) use of OAM based synthetic packet loss measurement instead of user
packets based packet loss measurement.

Regards,
Maarten
PS. > Which technology is gaining market share, packets and MPLS or TDM?
:-)
Multi service OTN is gaining a lot of market share in the coming period; see
recent analyst reports.
So answer to your question is: both. :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 3 augustus 2010 16:16
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: current practices (was Re: [mpls-tp] New ID

Maarten Vissers writes:
>  
> [maarten] For a long time I have been considering the TC marking as 
> the 4th survivability control type, similar to your description.
>  
> congestion of the preferred traffic is highly unlikely. Is there a 
> guarantee that congestion of the preferred traffic will **never** occur?
> Note that a misconnection is also unlikely in a transport network, but 
> there is **no guarantee** that it never occurs... And thus we are 
> required to check for misconnections.

We seem to be in agreement on current practice but you asked this question.
If the preferred traffic in the network core is well under 5% of total
traffic as many providers which support a healthy amount of consumer and
business Internet service indicate, then for equal capacity links it would
take an outage of 19 out of a cutset of 20 to not partition the network but
cause congestion for preferred traffic.
Since most core networks seldom have cutsets of more than 4-5 that are
likely to partition, while there is no *guarantee*, the probability of a
complete partition is higher than that of congestion for preferred traffic.

In practice, the major disasters in the US have created few if any
partitions in core networks, with only localized islands of connectivity
only forming, mostly within metros, more rarely in an aggregation tier.  Use
of layer-2 protection rather than a control plane has been a major
contributor to formations of islands in the metro where connectivity would
have otherwise been possible.

This must all be factored into the provider's business plan.  More
redundancy costs more but penalties result from SLA violations and severe
violations (hours or days of outage) causes customers to go to other
providers.

> [maarten] If congestion of preferred traffic never occurs, then SD 
> based on detection of packet loss or preferred traffic represents the 
> packets losts due to bit errors on the media. No need to develop any 
> other OAM tool from this perspective.

You seem to be getting it.  Using OAM based on congestion would move the
entire LSP and it would have a negative impact on preferred traffic.  The
protection for one link is the working for another.  The N links in a cutset
generally protect each other, so sending traffic twice when congestion is
detected would only turn slight congestion into severe congestion.

> [maarten] If congestion of preferred traffic could however in rare 
> cases occur (i.e. no guarantee that it will never occur), protection 
> will restore the service performance if SD is detected on the basis of
packet loss.

Like I said, this is factored into the business plan.  If a customer's town
or city is under water and has no power (or drinking water, etc), they tend
not to complain that their VPN was down during part of that time (unless
they provide emergency services and need a communications channel for more
than short range radio is able to provide).  If they are in an unaffected
area, they like to see their services remain up, particularly if a competing
provider remained up.

> [maarten] Broadcast bridge makes use of the p2mp connection capability 
> that MPLS-TP nodes have to support. P2mp capabilities in packet 
> technologies (MPLS(-TP), Ethernet) are not as simple as similar 
> capabilities in circuit technologies (PDH,SDH,OTN). If reuse of the 
> p2mp technique for protection switching is too much of a problem for 
> MPLS-TP nodes, then SD condition definition may have to be changed, 
> and e.g. could be based on synthetic packet loss detection; i.e. 
> detection of synthetic packet loss measurement
> (SPLM) OAM packets. With such SPLM OAM based SD condition it is 
> possible to deploy a "selector bridge".

It is still a bad idea.  I don't buy the argument that P2MP is better and
that is the reason we can ignore the inefficiency of this method.

> For layer-2 Ethernet VPN and IP VPN, the cost of carrying these 
> requires the support of e.g. a 2G Ethernet Private LAN service; i.e. 
> ODUflex would be used for private services above 1G and then replaces
MPLS-TP PW.
> It will also be cost effective to use ODUflex as a transport-LSP 
> replacement and carry multiple Ethernet Virtual Private Line/Tree/LAN 
> services in one e.g. 3.75G ODUflex between Ethernet switching points in
the network; i.e.

We will see about that.  We have done fairly extensive analysis of how
various technologies map into provider capital costs and our analysis does
not agree with your assertion.  We have also tried to gauge provider
preference on packet vs ODUflex through discussions with customers.  However
this is enough off topic that we should not discuss it further.

Regards,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 13:59:57 -0400

In message <[email-masked]>
Maarten Vissers writes:

Rest of discussion to /dev/null.  Enough has been said on how packet
networks and transport network differ today.

> packets based packet loss measurement.

Providers who use LM to trigger protection do so at their own risk.

If anyone asks for it, as a vendor we'd support it.  Tony Li used to
say that Cisco always provides plenty of rope for the customer to hang
themselves if that is what the customer wants.

We seem to be in agreement that a loss measurement that excludes
queueing loss is needed.  A LM that measured a specific TC would solve
the problem nicely if that TC was sufficiently overprovisioned.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 04 Aug 2010 01:21:35 +0200

Curtis,

After sending my last message yesterday on current practice I was reminded
about future practice and the possible difference with current practice. 

Current practice for many networks is a combination of voice and data for
consumers and businesses plus some VPN/private line services for businesses
and wholesale.

In future practice we will get a combination of voice, data and video in
which the video component will be 95% of the traffic. Video is loss and
delay sensitive.

MPLS-TP in access and metro domains will in future networks have to support
mainly video traffic. What impact will this have on current practice?

Furthermore, many european networks will have to support unbundling. MPLS-TP
networks in such case have to support many service providers and guarantee
loss and delay for a main part of the traffic for each.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: dinsdag 3 augustus 2010 18:32
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] current practices (was Re: New ID
draft-rkhd-mpls-tp-sd-00)

Curtis,

Regards,
Maarten

---

From: <[email-masked]>
Date: Wed, 4 Aug 2010 10:11:19 +0100

You are essentially correct here Maarten.

Video traffic will dwarf everything else.  Our current
business-critical/big-spend focus is on this sort of future traffic
...and go ask the mobile operators how this video is impacting their
networks.

To be fair however there are lots of types of video wrt implications on
delay (esp) and loss.  But it is a fairly easy conclusion to arrive at
that it's not a brilliant idea to be shipping certain types of this sort
of video traffic (esp real time events, eg major sports events) through
shed-loads of layer networks TOS to BOS...one wants such performance
sensitive high BW traffic to be as close to the BOS as possible.

Remember a key point I have made several times now:  One must minimise
the number of layer networks between the always-present TOS and BOS
because each layer network represents (i) a real capex/opex cost + (ii)
a set of DP/MP/CP protocols that can have various failure modes and thus
each layer network is a source of unreliability (which is also why
defect detecting OAM needs to be as simple/sparse as possible in the
layer networks we do keep, ie we want this OAM super-reliable...which
BTW also implies no AIS in the co-ps mode).

Further, just think of the customer reaction if these services suffered
from poor performance (eg due to congestion) at some critical epoch (or
indeed in general at some not insignificant level throughout the
event)....now think back to what I have been painstakingly trying to get
across (which feels like banging my head on a brick wall sometimes here)
wrt what transparency really demands of a transport network.....

Oh yes I almost forgot, Curtis compared 'voice' services and 'FR, ATM,
Ethernet, SDH, etc' services (sic) in a related mail a day or so ago and
I was not impressed with some of the arguments I saw expressed here.

Voice, as we generally use the term, is a TOS stream application...the
other TOS applications are message and file (this is an exhaustive
generic set wrt classification BTW).

Voice as a stream application has an essentially static QoS (delay/loss)
requirement but can assume any value of survivability importance.
Further, note that both TOS file and message applications can also
assume any survivability importance whilst having varying QoS
requirements.  This observation is critical.

Why?  Because if one is not owning/operating the real TOS layer network
where these external application interface with the network world then
one had better not be trying to judge their survivability importance in
some lower non-TOS layer network.  This is a very serious layer
(transparency) violation...remember that the most crucial point about
transparency is that a server MUST NOT try and attempt to infer meaning
(where survivability importance is only one semantic) of client symbols.

Note also that application X in client (VPN) Y can have a quite
different survivability importance from the same application X in client
(VPN) Z.  So it is very clear, even if one did violate the transparency
rules, that trying to infer a survivability semantic of a higher layer
network from a lower layer non-TOS transport network is a very bad thing
to contemplate anyway.

Many customers of transport networks who own the real TOS layer
networks, where the message/file/stream external applications reside,
would find it quite unacceptable for some server layer party to be
snooping their traffic and attempting to make decisions on what they
saw.....note also that a client layer network can simply encrypt their
traffic units and at a stroke render this layer coupling (=transparency
violation) useless anyway (which BTW is another reason why transport
networks need to be able operate only on the atomic unit of information,
ie the client bit).

BT's Wholesale and (esp) OpenReach lines of business have some very
demanding customers in this respect and their transparency requirements
are way more stringent than what I am noting here (Please do not ask me
to go into detail on this).  

Now FR, Ethernet, SDH, etc are all non-TOS layer networks (VPNs if you
like....but actually even public networks like the PSTN and Internet are
VPNs if one really thinks about it....which is why all VPNs need to have
strong performance isolation from each other as well as reachability
isolation...however I digress).  This means they MUST always carry a
true TOS higher network.  One implication of this is that E-NNIs are not
technically necessary in non-TOS layer networks, but another key
implication in the context of what is being discussed here is that the
only viable way to treat such clients is to treat all their bits (ie the
atomic information unit/symbol) equally and retain their ordering for
the reasons I noted above.  This is what transparency means practically
and if one cannot ensure this then one should not claim a transport
role.

The co-cs mode always provides transparency....its all down to how the
physics of resource partitioning and labelling works here.  Further, the
space resource form of the co-cs mode is always present at the very BOS
(ie regular time-slicing of resource is not the only form of the co-cs
mode).

If we want to use the co-ps mode (which uses irregular time-slices of
resource) to provide a transport service we should pay careful attention
to what I noted above....but from what I have seen and continue to see
wrt MPLS-TP, this seems not to be the case.  IMO MPLS-TP is now just
another spin of MPLS....something I have noticed that Curtis in
particular seems very keen on making sure is understood as a fact too.
Fair enough, but please don't claim MPLS-TP is a transport network.  How
can it be anyway when it still has PWs, sublayering, no consistent CI,
etc?

 regards, Neil 

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 04 August 2010 00:22
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] Future practice [was RE: current practices 
> (was Re: New ID draft-rkhd-mpls-tp-sd-00)]
> 
> Curtis,
> 
> After sending my last message yesterday on current practice I 
> was reminded about future practice and the possible 
> difference with current practice. 
> 
> Current practice for many networks is a combination of voice 
> and data for consumers and businesses plus some VPN/private 
> line services for businesses and wholesale.
> 
> In future practice we will get a combination of voice, data 
> and video in which the video component will be 95% of the 
> traffic. Video is loss and delay sensitive.
> 
> MPLS-TP in access and metro domains will in future networks 
> have to support mainly video traffic. What impact will this 
> have on current practice?
> 
> Furthermore, many european networks will have to support 
> unbundling. MPLS-TP networks in such case have to support 
> many service providers and guarantee loss and delay for a 
> main part of the traffic for each.
> 
> Regards,
> Maarten
> 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> If only 5% of the traffic is preferred (i.e. committed) 
> traffic, then congestion of this traffic will be highly 
> unlikely and I agree with you.
> 
> I have always been assuming that in a packet transport 
> network 20-30% of traffic would be preferred/committed 
> traffic and that some links may be overbooked on purpose or 
> accidently. Congestion probability would for such case be 
> non-zero. If we can assume for protection that there is never 
> more then 5% preferred/committed traffic in a packet network, 
> then life will be simple :-). Packet loss measurement in an 
> LSP or PW will be representing packets lost due to bit errors.
> 
> This all does not take away the issue with respect to 
> protecting an individual PW, service-LSP or transport-LSP on 
> the basis of a SD condition (caused by bit errors in physical 
> media). As long as SD is measured on the basis of measuring 
> the actual preferred/committed traffic, then SD condition 
> clears when traffic is removed from working; i.e. zero 
> packets transmitted, zero received ==> no loss ==> clear SD 
> ==> revert to working ==> detect packet loss on working ==> 
> declare SD on working again ==> switch ==> etc.
> 
> Under an SD condition on working entity, the framework 
> document describes that traffic is switched to protection 
> entity. This would clear the SD condition on working, and we 
> get oscillation.
> 
> Packet loss ratio is determined using user packets, and 
> switching those packets away from working entity to 
> protection entity will clear the SD condition. I.e. we get 
> oscillation.
> 
> The specifications in the survivability framework and loss 
> detection documents result in oscillations 
> (W->P->W->P->W->etc) when a packet loss based SD condition is 
> detected on working entity. This oscillation can be prevented 
> if one of the following changes is applied:
> 2) use of OAM based synthetic packet loss measurement instead 
> of user packets based packet loss measurement.
> 
> Regards,
> Maarten
> Multi service OTN is gaining a lot of market share in the 
> coming period; see recent analyst reports.
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Aug 2010 09:30:47 -0400

In message <[email-masked]>

Maarten,

I think we need to end this but I will point out that modern video is
elastic traffic (in the intserv sense, see RFC 1633).  To the extent
that not all video is modern, you may be right.  Time will tell.

Streaming video behaves very much like TCP in response to congestion,
changing the encapsulation (usually reducing the "high order bits"
first, color depth, fine resolution, small changes in color, etc).
Since broadcast video need only be distributed to the head end once,
it is not a big traffic contributor.  Video on demand can be.
Streaming video seems to be driving much of the growth in video
traffic and it is all Internet traffic today.

Video distribution that have no inherent real time requirement, such
as movies, are normally sent as elastic traffic and are not at all
delay sensitive.  The transfer time is usually well under the playback
time and RAM is cheap these days.  I have it on good authority that
some video distribution, such as TV news footage from affiliate
stations that is not played back live, is sent as MPEG4 files over TCP
and has been sent over the plain old Internet that way since the late
1990s.

Today for the most part video traffic is Internet traffic as that is
the most cost effective way to deliver it.  As long as the cost
remains an important issue and dedicated service is more expensive,
that will remain true.  That said, I know of at least one MSO using
dedicated 10G waves for P2MP video distribution because for their
situation a 10G wave is cheap and this is the simplest approach.

Any European mandated unbundling is a good thing IMHO but it does
require MPLS-TP, only fair treatment of traffic.  MPLS-TP is only one
approach.  There was a great deal of interest in stochastic fair
queueing with cascaded queues (to isolate deliberate offenders) in the
late 1990s as a means to better enforce fairness on the Internet.  So
far, bittorrent not withstanding, deliberate circumvention of fairness
has not been sufficiently widespread to resurrect that interest,
though it may be needed by US MSOs at some point.

The way I look at it is the fraction of traffic attributable to
services for which the customer is willing to pay a significant amount
of extra money will remain small relative to total traffic.  That
includes video.  Consumers gravitate toward the lowest cost that
delivers an equivalent quality and convenience.  For example, Netflix
movies delivered across the Internet are sufficiently convenient and
no less clear and therefore this type of service sets the price point
and eliminates any type of delivery that cannot deliver service at a
competitive price.  It remains to be seen if MPLS-TP will be a cost
competitive means of delivering video on demand.

Also - just step back a monment and do the math.  An HD channel is
about 20 Mb/s if I'm not mistaken, less on average with compression
for scenes with very little motion (burst to 20 Mb/s for worst case
such as explosive effect scenes).  If so, 1,000 HD channels is 20 Gb/s
(could be much less with a good encoding rather than fixed bit/sec
encodings from MPEG).  Internet traffic today is up to 300-400 Gb/s on
some US core links that I am aware of and growing rapidly, expected to
exceed 1 Tb/s in 3-5 years, maybe less.  Near the edges video
distribution, if sent as priority traffic, would be a more significant
factor.  The middle mile and last mile are problematic due to older
technology with very limited or no intellegence and buffering.

Current practices was off topic.  Speculation on the future delivery
of video is even more off topic.

Curtis