Subject: [mpls-tp] Performance monitoring & MPLS-TP

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 04 Feb 2009 22:35:09 +0000

Colleagues,

I've been thinking a little about how performance measurement in TDM
networks maps to performance measurement in packet based network recently in
a context unrelated to MPLS-TP.

I see the following in draft-gray-mpls-tp-nm-requirements

      A SES is declared for a one second interval when the ratio of
      lost packets to total transmitted packets in that one second
      interval exceeds a predetermined threshold.

I'm trying to reconcile that against SES in TDM and how one normally measure
performance in a packet network.

Collecting performance data in 1 second buckets is going to be expensive and
is not how performance of packet networks is typically done today.

If the service is TDM then minimal (even single) packet loss in MPLS-TP
could cause SES in the TDM stream. But for a packet service I am not sure
that such granularity is required - e.g. Packet services can often tolerate
some packet loss and so working on SES seems

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 04 Feb 2009 22:40:58 +0000

Oops I sent a bit too early see below

On 04/02/2009 22:35, "Ben Niven-Jenkins" <[email-masked]>
wrote:

> Colleagues,
> 
> I've been thinking a little about how performance measurement in TDM networks
> maps to performance measurement in packet based network recently in a context
> unrelated to MPLS-TP.
> 
> If the service is TDM then minimal (even single) packet loss in MPLS-TP could
> cause SES in the TDM stream. But for a packet service I am not sure that such
> granularity is required - e.g. Packet services can often tolerate some packet
> loss and so working on SES seems

Working on SES as a basis for performance measurement seems excessive.

I am a concerned that by trying to reuse existing TDM terminology and mould
it to a packet context we "over egg the pudding"[1].

Ben

[1] http://www.yourdictionary.com/over-egg-the-pudding

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 4 Feb 2009 15:35:14 -0800

Hi Ben,

> Working on SES as a basis for performance measurement seems excessive.

Agreed.

> it to a packet context we "over egg the pudding"[1].

Fully agreed. I think we need performance measurement/monitoring
requirements for the *packet context*.

rahul

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

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 4 Feb 2009 21:01:43 -0600

Dear all,

The performance management requirements specified in this draft are
driven by the objective of providing coherent and consistent
interpretation of the network behavior, in particular for hybrid
networks which consists of multiple transport technologies, including
packet-switched and circuit-switched technologies.

Circuit-switched (TDM) technologies have been using SES to derive UAS
(Unavailable Seconds), which in turn is used to verify against meeting
the SLA or not. 

Now for packet-switched technologies, SES is used in this draft for
MPLS-TP. But it is defined totally in "packet context", i.e. based on
packet loss ratio (as quoted by Ben from the nm-requirement draft), not
BER as in TDM.

Please note that the above objective is consistent with the ITU-T & IETF
Joint Working Team agreement (MPLS-TP_overview-22.ppt) on NM regarding
ITU-T PM objectives (see its slide 111).

Please also note that this SES definition is consistent with that
defined in Y.1653 for Ethernet (another packet-switched technology).

Regards,

Kam

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On
Behalf

> Of Rahul Aggarwal

> Sent: Wednesday, February 04, 2009 6:35 PM

> To: Ben Niven-Jenkins

> Cc: [email-masked]

> Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

> networks

> > > maps to performance measurement in packet based network recently
in a

> context

> > > I'm trying to reconcile that against SES in TDM and how one
normally

> measure

> > > Collecting performance data in 1 second buckets is going to be

> expensive and

> > > If the service is TDM then minimal (even single) packet loss in
MPLS-

> TP could

> > > cause SES in the TDM stream. But for a packet service I am not
sure

> that such

> > > granularity is required - e.g. Packet services can often tolerate
some

> packet

> > I am a concerned that by trying to reuse existing TDM terminology
and

> mould

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 05 Feb 2009 11:28:10 +0100

Ben,

You are reopening a discussion that we have had a couple of years ago when
we developed Y.1731. At this point in time many operators require Ethernet
VLAN PM support on the basis of Y.1731 (G.8021, G.7710 and Y.1563) and ETH
MEP functions in the latest packet transport network equipment designs are
supporting it. 
A similar packet loss performance monitoring requirement has been received
for (T-)MPLS equipment from operators, which applies now thus to MPLS-TP
equipment, and latest designs are supporting it.

The first non-TDM technology that I am aware of that required SES is ATM.
I.357 (1996) defines this SES for ATM.

As such, SES for packet transport network technologies is quite common
already and is expected to be supported by the latest designs, including
those based on MPLS technology.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: woensdag 4 februari 2009 23:41
To: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

On 04/02/2009 22:35, "Ben Niven-Jenkins" <[email-masked]>
wrote:

> networks maps to performance measurement in packet based network 
> recently in a context unrelated to MPLS-TP.
> 
> I'm trying to reconcile that against SES in TDM and how one normally 
> measure performance in a packet network.
> 
> expensive and is not how performance of packet networks is typically done
today.
> MPLS-TP could cause SES in the TDM stream. But for a packet service I 
> am not sure that such granularity is required - e.g. Packet services 
> can often tolerate some packet loss and so working on SES seems

Ben

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 10:38:13 -0000

Ben,

You are right.  Continuous time based metrics make little sense for
measuring the NP (network perf...different to QoS) of packet
networks....and less sense for cl-ps than co-ps as we don't even have a
constraining connection construct (ie fixed routing) that one could try
and break-back end-end HRX objectives against. (Aside=> You might appeal
to the fact that routing is fixed in both except under failures, but in
a cl-ps network node/link adds can also change routing....not so in
co-ps mode networks, connections should not be moved once established
except under failures or planned works.  So I have a big question mark
against any notion of apportioned objectives in a cl-ps
network.....though I think ITU have tried to specify these).

SES are also not as simple as some folks might think.  Andy Reid and I
did a great deal of error measurents in co-cs transport networks many
years ago and some of the key findings were (this is only a brief
snippet related to SES):

-	the error distributions are mathematically chaotic (ie
self-similar) in nature and for sure not Poisson.  What this means
practically is that it not generally possible to meaningfully time-scale
long-term objectives to shorter periods, eg a hour or day test of perf
for bringing into service (BIS)....the only good BIS test is 'no errors'
over short periods...and if there are errors have a much longer test of
that system.  This attempts to optimise failing 'good systems' whilst
still capturing 'bad systems' wrt cost/time of testing;

-	SES come in 2 flavours:  (i) a few ms burst as co-cs path
signals lose/recover frame alignment (from us error burst in
trannsmission systems)  (ii) total wipe-out of the second, often last a
few seconds.  In both cases the error probability during the burst is
0.5.  And back then I was amazed to see a roughly 50/50 population split
between these 2 types of SES.  There are ~3 orders of magnitude
difference in application impact of these 2 types of SES.  It was these
practical measurements that led to us proposing that 'short-breaks' be
measured as a different metric to single/isolated SES events in order to
correctly differentiate these 2 quite distinct cases.  And if you have
ever read Y.1711 you will note that I defined a short-break event in
here as >= 3 but <10 seconds of defect....and the above is one reason
why...here is another:  The classic definition of unavailability (>= 10
consec SES) means PM counters should be stopped after entering
unavailable time....this is so the PM counts do not get distorted and
become meaningless.  But this effect is also true for short-break
events, and this is why I also suspended any PM counting if a
short-break occurs in Y.1711.

A SES event is a very poor metric....and suffers from the same
specification problems as a DM (Degraded Minute) metric...which you will
note has been removed from perf measurement standards.  The problem with
both these metrics is that there were originally specified back in the
early 80s wrt to an assumed Poisson distribution of error events of (i)
>=10^-3 in a second for SES and (ii)  >=10^-6 in a minute (exc SES) for
DM.  A Poisson distribution of errors is only relevant in thermally
noise limited networks (eg old FDM networks, and not digital
networks....the latter being dominated by burst errors (pe=0.5) which,
as I noted earlier, have a chaotic distribution.

To ram home the nonsense of these metrics consider an error burst of
nomially 2ms with pe=0.5:
-	if slightly less than 2ms in length this would generate an ES
(Errored Second) + DM pair
-	if slightly greater than 2ms this would generate a ES + SES
pair.
So the same real world error event can give rise to 2 quite different
outcomes due to a very small change in duration.  Hopely this shows the
nonsense of the original definition of SES and DM.  IMO the only good
metric is an 'errored period'....and even this only makes sense for
characterising constant bit rate systems, as indeed one finds as a
bottom-of-stack section layer.

I consciously never got into PM measurements in Y.1711 because one can
spend a shed load of effort measuring them for little real value....much
better to use networks that don't need to be monitored to death in a
transport role.  And if you think how difficult this issue is for an
end-end PM measurement whose (access) meansurement points are fixed
across routing changes in the core, just consider the effects of trying
to measure PM in a set of nested TCM levels when routing has to change
(eg failures in co-ps mode, failures + add nodes/links in cl-ps case)
and when a new set of nested TCM level points are required. 

Hope that has given you a taster for what might lie ahead wrt PM in
packet networks.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: 04 February 2009 22:35
> To: [email-masked]
> Subject: [mpls-tp] Performance monitoring & MPLS-TP
> 
> Colleagues,
> 
> I've been thinking a little about how performance measurement 
> in TDM networks maps to performance measurement in packet 
> based network recently in a context unrelated to MPLS-TP.
> 
> normally measure performance in a packet network.
> 
> Collecting performance data in 1 second buckets is going to 
> be expensive and is not how performance of packet networks is 
> typically done today.
> 
> If the service is TDM then minimal (even single) packet loss 
> in MPLS-TP could cause SES in the TDM stream. But for a 
> packet service I am not sure that such granularity is 
> required - e.g. Packet services can often tolerate some 
> packet loss and so working on SES seems 
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 05 Feb 2009 11:41:41 +0100

Rahul,

> I think we need performance measurement/monitoring requirements for the
*packet context*.

Since 1996 (ATM) there is TDM based performance measurements/monitoring
(G.826,..) **AND** cell/packet based performance measurements/monitoring
(Y.357). I.e. more then 12 years ago this item was resolved.

In 2004, Y.1561 (MPLS PM) was approved. Y.1561 specifies in clause 5.5.8 the
SLB (severe lost block), which is equal to a SES.

"5.5.8	Packet severe loss block outcome
A severe loss block (SLB) outcome occurs for a block of packets observed
during time interval Tlb at ingress MP0 when the ratio of lost packets at
egress MPi to total packets in the block exceeds s1.
The value of time interval Tlb is provisionally set at 1 second. The value
of threshold s1 is provisionally set at 0.15. Evaluation of successive
blocks (time intervals) should be non overlapping."

As such we do not need any requirements, we already have those for a long
time.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rahul Aggarwal
Sent: donderdag 5 februari 2009 0:35
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Hi Ben,

On Wed, 4 Feb 2009, Ben Niven-Jenkins wrote:

> > expensive and is not how performance of packet networks is typically
done today.
> > MPLS-TP could cause SES in the TDM stream. But for a packet service 
> > I am not sure that such granularity is required - e.g. Packet 
> > services can often tolerate some packet loss and so working on SES 
> > seems
>

Agreed.

> I am a concerned that by trying to reuse existing TDM terminology and 
> mould it to a packet context we "over egg the pudding"[1].
>

rahul

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 10:55:50 +0000

Kam,

I think I know what the draft is trying to achieve but I don't think it is
that useful in the real world.

How does one map SES as defined for MPLS-TP to SES for TDM?
How does one map SES as defined for MPLS-TP to SLAs for packet services?

Today packet services typically aren't monitored for precise packet loss,
but rather shadow measurements are taken based on representative test flows
from which average performance is calculated.

It is my view that we need to think about what we think will be the
predominant use for MPLS-TP (Circuit Emulation services or packet services)
and optimise the performance management for those cases.

Stating that MPLS-TP equipment must collect actual packet drops in 1 second
buckets adds significant complexity which I suspect will not be required for
the majority of MPLS-TP services.

Ben

BTW I see no mention of SES in Y.1563

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 5 Feb 2009 08:23:31 -0600

Ben,

Y.1653 (http://www.itu.int/rec/T-REC-Y.1563-200901-P/en) defines SES in section 9.1. 

9.1        Severe Errored Second (SESETH)

A Severe Errored Second (SESETH) outcome occurs for a block of frames observed during a one second interval at ingress MP0 when the corresponding FLR (i.e. the ratio of lost frames to total frames in the block) at egress MPi exceeds s1. 

A provisional value s1 of 0.5 is proposed, and different values may also be chosen depending on the Class of Service (CoS). 

Evaluation of successive one second intervals is non‑overlapping. 

I don’t think we need to map the MPLS-TP SES to TDM SES. SES is used to derive UAS, which could then be used for SLA applications. 

Regards,

Kam

> From: Ben Niven-Jenkins [mailto:[email-masked]]

> Sent: Thursday, February 05, 2009 5:56 AM

> To: Lam, Hing-Kam (Kam); Rahul Aggarwal

> but rather shadow measurements are taken based on representative test

> flows

> Stating that MPLS-TP equipment must collect actual packet drops in 1

> second

> buckets adds significant complexity which I suspect will not be required

> for

> On 05/02/2009 03:01, "Lam, Hing-Kam (Kam)" <[email-masked]>

> >>> On 04/02/2009 22:35, "Ben Niven-Jenkins"

> > <[email-masked]>

> >>>> I've been thinking a little about how performance measurement in

> > TDM

> >>>>       A SES is declared for a one second interval when the ratio

> > of

> >>> Working on SES as a basis for performance measurement seems

> > excessive.

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 5 Feb 2009 10:41:59 -0500

Hi Kam,

The recent Q17/12 liaison provided comments on Y.1731.  It notes that the current assessment of SES in Y.1731 is not reliable. 

I agree with Ben – we need to determine how to interpret “MUST”. Use of Y.1731 should not be a “MUST”. And it doesn’t apply for all applications. There are alternative approaches.

Deborah 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Thursday, February 05, 2009 9:24 AM
To: Ben Niven-Jenkins; Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Ben,

Regards,

Kam

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 15:28:46 +0000

I have less of an issue with a severely errored block.

You and Maarten can throw standards at me and that's fine but some basic
questions.  How many PM implementations for Ethernet are there that
implement SES?  How many of those implementations are in use in a live
deployment?  How many Ethernet SLAs on today's Ethernet services are
specified in SES?

My concern is the document as-is is mandating PM measurement at 1 second
granularity on all MPLS-TP equipment.  I question whether that level of
granularity is required for the majority of MPLS-TP services.  I also
question how economical it is to actually collect such PM statistics in 1
second buckets.

If we don't need to map MPLS-TP SES to TDM SES, what is the purpose of an
MPLS-TP SES, what does it give us that current packet based PM doesn't
(finer level of PM granularity)? Is that additional functionality required
in all cases?

Ben

On 05/02/2009 14:23, "Lam, Hing-Kam (Kam)" <[email-masked]> wrote:

> A Severe Errored Second (SESETH) outcome occurs for a block of frames observed
> during a one second interval at ingress MP0 when the corresponding FLR (i.e.
> the ratio of lost frames to total frames in the block) at egress MPi exceeds
> s1. 
> 
> A provisional value s1 of 0.5 is proposed, and different values may also be
> chosen depending on the Class of Service (CoS).
> 
> I don’t think we need to map the MPLS-TP SES to TDM SES. SES is used to derive
> UAS, which could then be used for SLA applications.
> 
>  
> 
> Regards,
> 
> Kam
> 
>  
>

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 05 Feb 2009 23:30:59 +0100

Hello Ben,

> from which average performance is calculated.

How about basing SES on packet loss ration? If the frame loss ration
crosses a (pre-)set threshold a SES is declared.

> the majority of MPLS-TP services.

Note that it is NOT required to have these buckets for every
LSP or PW. It could be a limited pool of buckets.

> BTW I see no mention of SES in Y.1563

Is your copy missing clause 9.1?

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 06 Feb 2009 09:40:47 +0100

Ben,

A packet/frame based SES is standardized as a basic element in performance monitoring for packet/frame based technologies.

> granularity is required for the majority of MPLS-TP services.  I also question
> how economical it is to actually collect such PM statistics in 1 second buckets.

The same question is applicable for SDH and OTN equipment. Also on those types of equipment you will notice that every MEP (trail termination) function will be able to collect 1 second information. The equipment however will support such collection only for a specific number of MEP (trail termination) functions in parallel. The complexity in equipment is not the ability to count in a port card, the complexity is in the storage of 15 minute and 24 hour bins in the processor cards and collection of such information in the network.

During the development of Ethernet OAM the following information became available that addresses this complexity issue:
- it must be possible to enable/disable pro-active fault management and pro-active (bidirectional) performance monitoring on any service instance
- 90% of service contracts do not require pro-active monitoring, 10% of service contracts requires such pro-active monitoring
- the 10% of service contracts represents 30% of service instances
- about 70% of service instances with pro-active monitoring requirement require pro-active fault management only
- about 30% of service instances with pro-active monitoring require pro-active performance monitoring; this is about 10% of the number of services. Most of this monitoring is performed on UNI-N port cards, located in NTU/MTU devices or trib cards in ADMs or XCs. Complexity of those cards is typically not to high.
- about 30% of the service instances with pro-active performance monitoring requirement requires individual protection support. This adds TCM MEP functions to the NNI port cards in PE nodes. Packet/frame loss counting to determine the Signal Degrade fault condition is an option, but 15 minute/24 hour PM data collection is not required.

- all section and tunnel/path connections require pro-active fault management monitoring. The number of those sections and tunnels is however much smaller then the number of service instances.

- all section connections typically require pro-active performance monitoring. This performance monitoring is however unidirectional maintenance based PM (not the bidirectional service based PM necessary for the service monitoring).

- tunnels may or may not require pro-active (unidirectional) performance monitoring.

- for the case of protection switching of service instnaces, TCM MEPs are used, which are located on NNI port cards in PE nodes. Protection switching TCM MEPs do not require performance monitoring data collection; only requirement is optional support of Signal Degrade defect detection, which is a fault management function using the packet/frame loss counting mechanism. 

- for the case of multi-operator service instances, we have the requirement to support per service instnace TCM. For those service instances with pro-active PM, their operator-TCM MEGs must also support pro-active PM. This requires that a TCM MEP on the UNI-N port cards must support pro-active PM and that the TCM MEPs on E-NNI port cards must support pro-active PM. 
The UNI-N port card in e.g. NTU/MTU nodes will thus have to support two packet/frame loss counters per service isntance, but with a limited number of service instances per port card this does not introduce any real complexity.
The E-NNI port card however is a bit different. Here the multi-operator service instances come together and there are thus larger numbers of those service instances present then on a UNI-N port card. But when we assume that 70% of services is intra-metro and that only 30% of the other inter-metro services is actually inter-operator services, only 10% of the services will have to pass E-NNI port cards. With only 10% of the services having pro-active PM required, the number of packet/frame loss counters necessary on an E-NNI card is about 10% of the number of service instances support over such cards. That should not be an issue for today's hardware.

- For premium mp2mp and rmp services (which I refer to as TE-VLANs), there will be a requirement to monitor frame loss per ETH link connection. This adds an ETH frame loss counting requirement to the I-NNI and E-NNI port cards in PE nodes. But again, if we assume that the number of mp2mp and rmp services in a network is not more then 30% of total service instances, and combine this with 10% of services requiring pro-active PM, there is a requirement to support for 3% of the services pro-active PM for ETH link connections on I-NNI/E-NNI port cards in PE nodes. Again this should not be a real issue with today's hardware.

I hope that you understand that UNI-N and (I-/E-)NNI port cards on PE nodes typically will support pro-active PM 1-second packet/frame loss counting for a subset of the service instances supported. The network element will futhermore support a limited number of PM 15 min/24 hour registers, which number will typically be less then the sum of 1-second counters available on the UNI/NNI port cards in the network element.

Nonetheless those restricted sets of 1-second counters on port cards and 15min/24hour registers on controller cards, it is possible to support pro-active PM for every service instance (and section/tunnel instnaces); it is only not possible to support such pro-active PM for all service instances at the same time.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: donderdag 5 februari 2009 16:29
To: Lam, Hing-Kam (Kam); Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

You and Maarten can throw standards at me and that's fine but some basic questions.  How many PM implementations for Ethernet are there that implement SES?  How many of those implementations are in use in a live deployment?  How many Ethernet SLAs on today's Ethernet services are specified in SES?

My concern is the document as-is is mandating PM measurement at 1 second granularity on all MPLS-TP equipment.  I question whether that level of granularity is required for the majority of MPLS-TP services.  I also question how economical it is to actually collect such PM statistics in 1 second buckets.

If we don't need to map MPLS-TP SES to TDM SES, what is the purpose of an MPLS-TP SES, what does it give us that current packet based PM doesn't (finer level of PM granularity)? Is that additional functionality required in all cases?

Ben

On 05/02/2009 14:23, "Lam, Hing-Kam (Kam)" <[email-masked]> wrote:

> A Severe Errored Second (SESETH) outcome occurs for a block of frames 
> observed during a one second interval at ingress MP0 when the corresponding FLR (i.e.
> the ratio of lost frames to total frames in the block) at egress MPi 
> exceeds s1.
> 
> A provisional value s1 of 0.5 is proposed, and different values may 
> also be chosen depending on the Class of Service (CoS).
> 
> I don’t think we need to map the MPLS-TP SES to TDM SES. SES is used 
> to derive UAS, which could then be used for SLA applications.
> 
>  
> 
> Regards,
> 
> Kam
> 
>  
>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 Feb 2009 12:10:34 +0100

Dear Deborah,

You replied:

> The recent Q17/12 liaison provided comments on Y.1731.

The rapporteur of Q17/12 was so kind to send me a copy of the
liaison that you refer to. It is cuurently processed by TSB and
as sson as it is available I will send the link.

The comments are in short:
-1- request to revise loss measurement based on counters in
     *connectionless* technologies
-2- request to align Y.1731 with Y.1563 (currently under revision)
     because the references to MEF-10 are outdated/superseded.
-3- repeat the request to clarify the reference to RFC2544 when
     measuring Troughput.
-4- revise the definition of FrameLossRation, FrameDelay and
     FrameDelayVariation.

 > It notes that the current assessment of SES in Y.1731 is not
 > reliable.

SES is not mentioned at all in Y.1731. Y.1731 only mentions Availability
i.e. that the definition of Availability is out of scope.

Q17/12 proposes to refer to Y.1563 that contains the definition of
SES for packet tchnologies. And that ETH_LM and CCM PDUs can be used
to determine SES.

> I agree with Ben – we need to determine how to interpret “MUST”. Use of 
> Y.1731 should not be a “MUST”. And it doesn’t apply for all 
> applications. There are alternative approaches.

Like Y.1563.

Regards, Huub.
==============
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Lam, Hing-Kam (Kam)
> *Sent:* Thursday, February 05, 2009 9:24 AM
> *To:* Ben Niven-Jenkins; Rahul Aggarwal
> *Cc:* [email-masked]
> *Subject:* Re: [mpls-tp] Performance monitoring & MPLS-TP
> 
>  
> 
> Ben,
> 
>  
> 
>     9.1        Severe Errored Second (SES_ETH )
> 
> A Severe Errored Second (SES_ETH ) outcome occurs for a block of frames 
> observed during a one second interval at ingress MP_0 when the 
> corresponding FLR (i.e. the ratio of lost frames to total frames in the 
> block) at egress MP_i exceeds *s_1 *.
> 
> A provisional value s_1 of 0.5 is proposed, and different values may 
> I don’t think we need to map the MPLS-TP SES to TDM SES. SES is used to 
> derive UAS, which could then be used for SLA applications.
> 
>  
> 
> Regards,
> 
> Kam
> 
>  
> 
> ------------------------------------------------------------------------
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 06 Feb 2009 12:22:55 +0100

Hi Deborah,
 
Y.1731 does not specify any SES assesment. Y.1731 specifies a frame loss counting mechanism that provides the means to detect the number of lost frames. G.8021, G.806 and G.7710 then specify how this information is used to determine if a second is a serverely errored second.
 
C618 (SG15, June 2007) http://www.itu.int/md/T05-SG15-C-0618/en was the input to extend G.806, G.7710 and G.8021 and G.8121 with the necessary packet/frame based performance monitoring process specifications.
 
The Q.17/12 draft liaison statement in http://wftp3.itu.int/packet/Dec2008_Q17/OUT-docs/LS_SG13_Y1731.doc <http://wftp3.itu.int/packet/Dec2008_Q17/OUT-docs/LS_SG13_Y1731.doc>  describes on page 1:

-----------------------
"The counter-based Loss measurement described in section 8.1 (ETH-LM) may have various sources of error when connectionless transport technologies are used to implement Ethernet networks. For example: 

1.          Frames may be counted at either MP which did not pass the other MP (intentionally).

2.          Where the order of frame delivery can change between MPs, then the frame counts carried in OAM frames may not be valid.  This is especially true when the OAM frame itself is delivered out-of-order, or when a frame re-ordering event takes place in the vicinity of an OAM frame.

3.          Frame duplication may occur under some circumstances.

As a result of these error sources, there is a need to perform loss measurements that can be used reliably in SLAs. The frame correspondence requirement and Tmax timeout of Y.1563 should be included in the solution.  A mechanism similar to Frame Delay Measurement ETH-DM may be sufficient, on an on-going basis (not only on-demand). 

If this need is not met in Y.1731, alternate solutions may be sought and implemented in the industry."
-----------------------
 
Looking at this text, I have the impression that the Q.17/12 participants did miss the 2nd and 3rd sentences in clause 8 of Y.1731: "The performance parameters are defined for point-to-point ETH connections. Performance parameters and functions for multipoint ETH connectivity are for further study.". 
These sentences indicate that the frame loss counting mechanism is designed for use in point-to-point Ethernet connections. This can be point-to-point VLANs or point-to-point ETH link connections in a mp2mp or rmp VLAN.

Issue 1. reported in the liaison statement is as such not applicable; all frames pass both (i.e. all) MPs in a p2p ETH connection.

Issue 2. is also addressed by Y.1731's specification of frame loss measurement. Frame loss is counted for frames belonging to one priority level. Those frames will pass through the same queue(s) in the p2p ETH connection, and there will be no reordering of frames. 

It has been noted that the Link Aggregation schemes that distribute the MAC frames over the individual links independent of the VLAN they belong to can not be used in an Ethernet network that runs Ethernet performance monitoring as it could/would cause reordering of frames belonging to one VLAN and one priority level. Connection aware link aggregation schemes are under development; refer to the CTG and CL-SNCG/I work in SG15 and MEF.

If frame replication occurs (issue 3.), then the Y.1731 frame loss measurement will detect this as the receipt of an additional frame. I don't know what will cause frame duplication on p2p ETH connections, so I am not sure if this a real issue. 

When two ETH connections merge (i.e. a mismerge condition), then the MEP Sink function will receive a lot of additional frames. The Y.1731 frame loss counting process will detect that there are more frames received then expected (i.e. transmitted) and will be able to report this. This information is superfluous when the merging ETH flow domain fragment runs CCM; in this case a mismerge defect (dMMG) will be detected. For the other case, (no CCM in merging flow domain fragment being used) the detection of more frames then expected will be used as trigger condition for fault repair.

My conclusion therefore is that the frame loss measurement specifications in Y.1731 seems to be correctly supporting pro-active performance monitoring in p2p ETH connections (p2p VLANs, p2p ETH link connections in mp2mp or rmp VLANs).

This now leaves the method to perform pro-active performance monitoring in mp2mp or rmp VLANs. Pro-active PM is only required in premium mp2mp and rmp VLAN service instances. Such premium mp2mp/rmp VLANs are Traffic Engineered VLANs. Traffic Engineering implies that the CIR/EIR of the individual p2p ETH link connections within a mp2mp/rmp VLAN are guaranteed. This implies that pro-active PM in a mp2mp/rmp TE-VLAN needs to monitor the frame loss on the set of traffic engineered p2p ETH link connections within such TE-VLAN.

I have described this pro-active PM of p2p ETH link connections within a mp2mp/rmp TE-VLAN/VPLS in section 2.1.1 of http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-types-and-characteristics-00.doc and of http://ifa.itu.int/t/2009/sg15/exchange/wp3/q9/2009-02-Beijing/cd/eth_eq/eth-vlan-equipment-types-and-characteristics-03d.doc.

The liaison statement also states on page 2:
--------------------------
"1.	Y.1563 defines performance parameters for Ethernet networks, so the second sentence should be modified to reflect the scope of Y.1731: Methods of measurement are defined for point-to-point ETH connections.
2.	Y.1563 defines multipoint ETH performance parameters, so they are no longer for further study as stated in sentence 3.  However, the measurement methods are yet to be determined.
3.	The last sentence should primarily reference Y.1563. Also, MEF 10 has been revised, and we encourage a secondary reference to the most recent version, including any amendments."
--------------------------

Y.1731 describes the pro-active PM for p2p ETH connections. Those connections can be p2p VLANs (i.e. p2p ETH flow domain fragments) or p2p ETH link connections. As described above, pro-active PM of mp2mp and rmp TE-VLANs is implemented by monitoring the p2p ETH link connections for frame loss. The mp2mp/rmp TE-VLAN in total is monitored for status only (continuity, connectivity).

Y.1731 should be extended in the next Q.10/15 meeting to describe the pro-active performance monitoring of mp2mp/rmp TE-VLANs on the basis of performance monitoirng of the traffic engineered p2p ETH link connections.

Recently, Q.9/15 and Q.14/15 have discussed the pro-active and on-demand performance monitoring details in Ethernet. The conclusion of that discussion was that ETH LMM/LMR will be used only for on-demand, single-shot frame loss measurement with immediate report of the result at the end of the measurement. I believe that it would be good to represent in Y.1731 the results of this Q.9/15+Q.14/15 discussion.

Regards,
Maarten

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: donderdag 5 februari 2009 16:42
To: Lam, Hing-Kam (Kam); Ben Niven-Jenkins; Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Hi Kam,

Deborah 

Ben,

Regards,

Kam

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 07:37:24 -0600

Ben,

	Part of the basis for this discussion is the tension between
two camps mentioned earlier: one camp wants to create a service
definition for circuit-switched-like services over a packet-switched
network, and another wants to adapt circuit-switched applications to
work over a packet-switched network (as close as possible to as is).

	This theme emerges time and again.  Perhaps we need to resolve
whether or not it is really our intention to accomplish what the JWT
agreed to do (define a transport profile for MPLS as intended in the
definition of "T-MPLS" by ITU study groups), or grind away at some
other set of objectives.

	As has been pointed out, in this discussion, in the discussion
at Ipswich and in our draft, SES is defined in a packet-switched
context.   You could argue "if it ain't IP, then it ain't packet 
switching" but this is a specious argument.  SES is used in Ethernet 
networks, to accomplish the precise requirement we are discussing 
(consistent error reporting for multiple technologies) and Ethernet 
is a "packet" switching technology.

	We can argue all day about the accuracy of measuring SES over
a packet-switched network (obviously), but that will not change the
fact that some of our customers (both the ones who buy our equipment
and the ones who hope to use our standards) want to see performance
reported in these terms by this technology - just as it is by almost
every other technology.

	The only problem I personally have with changing this is the 
high probability that we would then drown in liaisons from the ITU, 
and that this could lead to a failure in the JWT objectives.  If we
want to insist that we can't use ITU defined criteria for measuring
performance, and this leads to a break-down in cooperation with the
ITU, it's all of our funerals.  

	Hence we are trying to see what we might be able to do with 
the work David Ward has pointed out.  We are not quite ready for 
prime time on this subject, so it is our intention to publish the
next version (in a few minutes) with the SES text as is.  We have 
- in our current Word source document - a comment that this is yet
to be resolved, and so it is...

--
Eric

-----Original Message-----
Behalf Of Ben Niven-Jenkins

Kam,

I think I know what the draft is trying to achieve but I don't think it
is
that useful in the real world.

Today packet services typically aren't monitored for precise packet
loss,
but rather shadow measurements are taken based on representative test
flows
from which average performance is calculated.

It is my view that we need to think about what we think will be the
predominant use for MPLS-TP (Circuit Emulation services or packet
services)
and optimise the performance management for those cases.

Ben

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 08:46:48 -0600

Deborah,
 
    Requirements levels can be pretty tricky.  For example, if there is 
a set of customers (or applications) that require a feature, and another
set that does not require the feature, then we can say the following 
requirement levels apply:
 
1) The feature MAY be used in deployments;
2) The feature MUST be supported in implementations targeting such
    deployments, if failing to support it would take the above choice 
    away from the customer;
3) The standard MUST define and require the support implementations
    MUST provide.
 
Hence in spite of the fact that some subset of all users (or applications) 
of a standard are less than excited about a feature, the standard MUST 
address it, and implementations MUST support it or it is effectively not 
available at all, to anyone.
 
    If your intention is to say that - because you are not interested in the
definitions provided by Y.1731 - nobody is allowed to be interested, or any
one having such interests is to be excluded from the target customer set,
then this is what you should say.
 
    I suspect that will be a problem from the perspective of the JWT.
 
    If you would like to put forward some other definitive source for how 
performance may be monitored in a way you would like to use, so that 
we can similarly require support for that as well, then please do so.
 
    Simply not saying anything is not the answer.
 
    Thanks!
 
--
Eric

From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, February 05, 2009 10:42 AM
To: Lam, Hing-Kam (Kam); Ben Niven-Jenkins; Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Hi Kam,

Deborah 

Ben,

Regards,

Kam

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 15:39:58 -0000

My 2c on this general topic of OAM/PM:
 
A properly designed co-cs or co-ps mode layer network should not require shed-loads of OAM running on it...esp PM OAM.   If it does....because one has been daft enough to create mp2p or mp2mp merging constructs which cannot have practical resource management.....then you fix the design problem, you don't monitor the network to death.  
 
There are other nasty side effects of violating the rules for connections, such as:
-    you run the network largely empty because you are scared of performance problems happening
-    you have to design/operate the whole network to the most demanding customer SLA in place 
-    your technically savvy customers are aware you cannot manage resource and demand that you make a raft of detailed PM measurements of their service
 
This all costs money...and it's wasted money simply because the design was wrong in the first place.
 
OAM is not (despite what some might claim) the same for all 3 network modes.  For example, whilst request/response OAM is correct for path tracing in a cl-ps network this is not reliable in a co-cs or co-ps mode network (simply because traffic leaking from a connection is unlikely to have a return path).
 
OAM does not have to be complex...in fact it should be as sparse/simple as possible because it MUST be orders more reliable than the network it sits in.  This aspect is particularly true for the 'always-on' OAM required to detect/handle defects.  Diagnostics OAM (and I'd include PM in this for most cases) can be a more complex because you expect to only rarely use it 'on-demand'.
 
Anything that has lots of configuration should be avoided like the plague (one reason being it will be a key source of unreliability itself)...and I'd ask some very hard questions about nested TCM sublayers in this respect, which as minimum need good answers to these 2 aspects before they should be progressed:
-    how do nested TCM levels get correctly activated/deactivated across routing changes?....because only the connection end-points will remain consistent across such events
-    how do any nested TCM PM counters that are running get synchronised across such old/new routing changes?
 
And for those amongst us who think E-NNIs make sense when not top-of-stack the above should also factor-in different party ownership of TCM nested measurement points embedded in some other party's equipment (noting that this may constrain where rerouted traffic can go).
 
Funny how most networks have managed to exist so long perfectly with with very little OAM/PM (add in here the enduringly successful Internet and PSTN)....maybe these were the ones that were designed right in the 1st place ;-)
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
	Sent: 06 February 2009 14:47
	To: BRUNGARD, DEBORAH A, ATTLABS; Lam, Hing-Kam (Kam); Niven-jenkins,B,Ben,DMF R; Rahul Aggarwal
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

	Deborah,

	 

	 

	    Thanks!
	 
	--
	Eric

	Hi Kam,

	Deborah 

	Ben,

	Regards,

	Kam

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 10:14:46 -0600

Neil,
 
    This is yet another manifestation of the same "tension" I mentioned earlier.
 
    The Internet - like Ethernet - is successful primarily because the expectations
that define "success" for these technologies are very low.  Unreliable, best effort,
delivery expectations define success in such a way that makes it hard to fail.
 
    Consequently, the technologies are relatively cheap and - for applications that
can accept services with such low expectations - cost is effectively the only factor
that applies.  As you know, it turns out there are a lot of such applications.
 
    But "applications that can accept services with such low expectations" is a
huge caveat.
 
    Hence the tension: do we adapt applications to accept a lower standard for
acceptable service, or do we adapt (part of) the service to meet a higher standard.
Again, cost is a primary factor, and one thing you will almost always discover is
that there are applications for which the "cost" of less reliable delivery is far higher
than the "cost" of providing a more reliable service.
 
    Ultimately, it is difficult to imagine how it will ever be the case that this type of
application will go completely away.
 
    This is - after all - the reason why we define "premium services."
 
    Naturally service providers would like to provide premium services for the same
cost as regular services.  It's a great (and possibly legal) way to print money.
 
    But there are applications out there for which lost seconds are very expensive.
And, as these applications become a smaller and smaller fraction of the gestalt
of all services provided, service providers must inevitably arrive at a point where it
is probably less expensive to support the extra do-hickeys required to provide a
reliable service over an inherently unreliable network, then it is to maintain reliable
network infrastructure for a diminishing fraction of the services sold (and at a flat
cost that is unlikely to get smaller in comparison).
 
--
Eric

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 10:40 AM
To: Eric Gray; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

 

 

 
 
regards, Neil

	Deborah,

	 

	 

	    Thanks!
	 
	--
	Eric

	Hi Kam,

	Deborah 

	Ben,

	Regards,

	Kam

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 06 Feb 2009 17:47:04 +0000

Eric,

I understand from Huub and Maarten's e-mail that such SES statistics are not
collected on all paths simultaneously but only on a subset of paths. I am a
little more comfortable with this as it somewhat lessons the impact on
equipment. Is it possible to say something about this in the draft - i.e.
That although collection of SES is a MUST, that does not mean it has to be
supported for all paths simultaneously?

Thanks
Ben

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Fri, 6 Feb 2009 12:09:30 -0600

Ben,

The current requirement says:
"The MPLS-TP NE MUST support collection of SES ..." 
                     ^^^^^^^

That means the NE MUST have that capability. It doesn't mean it has to
execute the collection on every LSP instance. I think we can add
clarification text along this in the next round.

Regards,
Kam

> Sent: Friday, February 06, 2009 12:47 PM
> To: Eric Gray; Lam, Hing-Kam (Kam); Rahul Aggarwal
> Cc: [email-masked]
> I understand from Huub and Maarten's e-mail that such SES statistics
are
> not
> collected on all paths simultaneously but only on a subset of paths. I
am
> a

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 19:00:02 -0000

Can I ask a simple question please Kam.....

Availability is a key metric/objective for *all* services (more
important than any general PM metric/objective), but is this not
dependent on measuring SES (assuming the unavailable state entry
criteria is still 10 consecutive SES)?  So if wants wants to measure
unavailability of all LSPs does this then not mean a measurement of SES
on all LSPs is required?

regards, Neil 

> [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
> Sent: 06 February 2009 18:10
> To: Niven-jenkins,B,Ben,DMF R; Eric Gray; Rahul Aggarwal
> Cc: [email-masked]
> That means the NE MUST have that capability. It doesn't mean 
> it has to execute the collection on every LSP instance. I 
> think we can add clarification text along this in the next round.
> 
> Regards,
> Kam
> 
> 
> > > Part of the basis for this discussion is the tension between two 
> > > camps mentioned earlier: one camp wants to create a service 
> > > As has been pointed out, in this discussion, in the discussion at 
> > > Ipswich and in our draft, SES is defined in a packet-switched
> > > We can argue all day about the accuracy of measuring SES over a 
> > > packet-switched network (obviously), but that will not change the 
> > > The only problem I personally have with changing this is the high 
> > > probability that we would then drown in liaisons from the 
> ITU, and 
> > > that this could lead to a failure in the JWT objectives.  
> If we want 
> > > to insist that we can't use ITU defined criteria for measuring 
> > > Hence we are trying to see what we might be able to do 
> with the work 
> > > David Ward has pointed out.  We are not quite ready for 
> prime time 
> > > on this subject, so it is our intention to publish the 
> next version 
> > > (in a few minutes) with the SES text as is.  We have
> > > I think I know what the draft is trying to achieve but I 
> don't think
> it
> > > is
> > > loss, but rather shadow measurements are taken based on 
> > > representative
> test
> > > flows
> > > second buckets adds significant complexity which I 
> suspect will not 
> > > be
> required
> > > for
> > >> MPLS-TP. But it is defined totally in "packet context", 
> i.e. based
> on
> > >> packet loss ratio (as quoted by Ben from the 
> nm-requirement draft),
> > > not
> > >> BER as in TDM.
> > >>
> > >>
> > >>
> > >> Please note that the above objective is consistent with 
> the ITU-T &
> > > IETF

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 13:07:51 -0600

Ben,

	We've just been discussing this.  We have information on 
measurement instrumentation in our current section 7.2, but we
feel we should have explicitly added knobs to allow configuring
this for a subset of LSPs (probably in the section on LSP/Path 
configuration).

	We also feel that it is worth a note to indicate that it
is likely that SES/UAS measurement will only apply to a subset
of LSPs - if it is used at all - and this in turn argues for a
default position of the "knob" to be "off." 

	I imagine in MIB-ese, that will mean that a MIB entry 
would only exist for an LSP where this measurement is enabled.
This is very similar to how maintenance points are configured
for Ethernet devices.

--
Eric

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 12:47 PM
To: Eric Gray; Lam, Hing-Kam (Kam); Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

Eric,

I understand from Huub and Maarten's e-mail that such SES statistics are
not
collected on all paths simultaneously but only on a subset of paths. I
am a
little more comfortable with this as it somewhat lessons the impact on
equipment. Is it possible to say something about this in the draft -
i.e.
That although collection of SES is a MUST, that does not mean it has to
be
supported for all paths simultaneously?

Thanks
Ben

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 15:30:43 -0600

Neil,

	Answering for myself, if LSPs were only being used to provide 
premium services, the answer would be yes.  But if that were the case,
then interoperability with existing MPLS deployments would probably
not be so important.

	Where the complexity comes in is in mixing LSPs - where some are
used to support best efforts services (potentially for BE VPN services)
some are used for pseudo-wires and some are in support of MPLS-TP.

	Clearly measurement is only required for specific services that
require it (tautology 101).

	Also, for those services that are not attempting to emulate a
connection-oriented service, availability may be more easily determined
by ascertaining that one retains a connection to the cloud.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 2:00 PM
To: [email-masked]; [email-masked]; Eric Gray;
[email-masked]
Cc: [email-masked]

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 06 Feb 2009 22:44:23 +0000

Thanks. Ben

---

From: <[email-masked]>
Date: Sat, 7 Feb 2009 10:59:19 -0000

Thanks Eric....replying (in some senses to self): 

Eric Gray wrote 06 February 2009 21:31
> 	Answering for myself, if LSPs were only being used to 
> provide premium services, the answer would be yes.

NH=> There is actually no choice but to monitor all LSPs (irrespective
of their importance) in order to spot instances of leaking traffic.
This is a consequence of not having an absolute SA in the traffic unit
and using label-swapping.  Granted you don't have to measure SES on each
LSP however.....but you will if you want to define entry/exit (and ES
for exit) for the unavailable state. 

> But if 
> that were the case, then interoperability with existing MPLS 
> deployments would probably not be so important.
NH=> I think this 'interoperability' card is being played far too
strongly.  Whether one likes it or not MPLS-TP will be a different layer
network to MPLS......which itself is neither singular nor indeed can be
classified as proper layer network since it does not have consistent
characteristic information.  These issue must be fixed in MPLS-TP.  So
interworking as peers is *not* the way one should look at this, what is
more important is to get the client/server aspect right so that MPLS-TP
can carry all clients (inc MPLS and MPLS-TP) transparently.

> 
> 	Where the complexity comes in is in mixing LSPs - where 
> some are used to support best efforts services (potentially 
> for BE VPN services) some are used for pseudo-wires and some 
> are in support of MPLS-TP.
NH=> If PWs as *a layer network* get carried forward into MPLS-TP then
MPLS-TP will have failed....and IETF will not be able to claim it is a
'transport network'.  If PWs are carried over into MPLS-TP then they can
only do so as an adaptation function.  This is a very important
point...and I cannot stress it strongly enough.
> 
> 	Clearly measurement is only required for specific 
> services that require it (tautology 101).
> 
> 	Also, for those services that are not attempting to 
> emulate a connection-oriented service, availability may be 
> more easily determined by ascertaining that one retains a 
> connection to the cloud.
NH=> Have you ever tried that argument on paying customers?

regards, Neil
> To: [email-masked]; [email-masked]; 
> Eric Gray; [email-masked]
> Cc: [email-masked]
> Availability is a key metric/objective for *all* services 
> (more important than any general PM metric/objective), but is 
> this not dependent on measuring SES (assuming the unavailable 
> state entry criteria is still 10 consecutive SES)?  So if 
> wants wants to measure unavailability of all LSPs does this 
> then not mean a measurement of SES on all LSPs is required?
> 
> regards, Neil 
> 
> > > That although collection of SES is a MUST, that does not 
> mean it has
> > to be
> > > >> Circuit-switched (TDM) technologies have been using 
> SES to derive
> > UAS
> [mailto:[email-masked]]
> > On
> > > >> Behalf
> > > >>
> > > >>> Of Rahul Aggarwal
> > > >>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 08:34:49 +0100

Eric,

LSPs are providing the tunnel connections in the MPLS-TP network. Tunnels
carry aggregates of transport service connections (PWs, VPLSs). In a well
designed network, the number of tunnels will be much smaller then the number
of transport service connections.

As an example, in a network with 5000 metro edge offices which are
partitioned into 100 metro domains, each having 50 metro edge nodes, you
will have:
- 4 tunnels terminating in a metro edge node (two protected pairs of
tunnels), which connect each metro edge node with one of the two metro core
nodes (case of hub&spoke metro); this number will increase a bit when the
metro domain has a partial mesh of tunnels
- 98 (49 protected pairs of) metro tunnels terminating in a metro core node
per metro domain
- 98 (49 protected pairs of) core tunnels terminating in a metro core node
for the core domain.
There are as such not too many tunnels per interface port to support, so it
should be possible to support 100% tunnel (i.e. LSP) monitoring. I.e. by
default the "knob" could be "on".

The large number of connections (millions) are to be found in the MPLS-TP
MS-PW and VPLS (i.e. ETH) layers. In those transport service layers it is
important to support SES/UAS measurement to a subset of those PWs/VPLSs. By
default the "knob" will be "off". Especially as this pro-active PM is a
service element which only a subset of services will require.

The smallest number of connections are to be found in the transmission media
section layer (e.g. MPLS-TP Section or ETH Section). I would expect SES/UAS
measurement by default to be "on".

The MPLS-TP PW MEP (like the ETH MEP) function today will have support of
packet loss measurement as a configurable feature. The MPLS-TP LSP MEP
function will also have such packet loss measurement as a configurable
feature.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Gray
Sent: vrijdag 6 februari 2009 20:08
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Ben,

	We've just been discussing this.  We have information on measurement
instrumentation in our current section 7.2, but we feel we should have
explicitly added knobs to allow configuring this for a subset of LSPs
(probably in the section on LSP/Path configuration).

	We also feel that it is worth a note to indicate that it is likely
that SES/UAS measurement will only apply to a subset of LSPs - if it is used
at all - and this in turn argues for a default position of the "knob" to be
"off." 

	I imagine in MIB-ese, that will mean that a MIB entry would only
exist for an LSP where this measurement is enabled.
This is very similar to how maintenance points are configured for Ethernet
devices.

--
Eric

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Friday, February 06, 2009 12:47 PM
To: Eric Gray; Lam, Hing-Kam (Kam); Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

Eric,

Thanks
Ben

On 06/02/2009 13:37, "Eric Gray" <[email-masked]> wrote:

> Ben,
> 
> Part of the basis for this discussion is the tension between two camps 
> mentioned earlier: one camp wants to create a service definition for 
> circuit-switched-like services over a packet-switched network, and 
> another wants to adapt circuit-switched applications to work over a 
> packet-switched network (as close as possible to as is).
> 
> This theme emerges time and again.  Perhaps we need to resolve whether 
> or not it is really our intention to accomplish what the JWT agreed to 
> do (define a transport profile for MPLS as intended in the definition 
> of "T-MPLS" by ITU study groups), or grind away at some other set of 
> objectives.
> 
> (consistent error reporting for multiple technologies) and Ethernet is 
> a "packet" switching technology.
> 
> packet-switched network (obviously), but that will not change the fact 
> that some of our customers (both the ones who buy our equipment and 
> the ones who hope to use our standards) want to see performance 
> probability that we would then drown in liaisons from the ITU, and 
> that this could lead to a failure in the JWT objectives.  If we want 
> Hence we are trying to see what we might be able to do with the work 
> David Ward has pointed out.  We are not quite ready for prime time on 
> this subject, so it is our intention to publish the next version (in a 
> few minutes) with the SES text as is.  We have
> - in our current Word source document - a comment that this is yet to 
> be resolved, and so it is...
> 
> --
> Eric
> 
> loss, but rather shadow measurements are taken based on representative 
> test flows from which average performance is calculated.
> 
> second buckets adds significant complexity which I suspect will not be
required

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Feb 2009 09:02:59 +0100

Neil,

G.7710 describes the processing steps to get to available time and
unavailable time for both circuit and packet technologies. 10 consecutive
SES or non-SES seconds will change the status available=>unavailable,
unavailable=>available time.

As the number of LSPs (i.e. tunnels) in a MPLS-TP network will be much
smaller then the number of transport service connecitons (PWs,VPLSs), it
should be no problem to measure unavailability of all LSPs. 

But for PWs/VPLSs, you must restrict your unavailability measurements to a
subset; i.e. to the subset of PWs/VPLSs for which the SLA requires
pro-active Performance Monitoring. When your network supports e.g. 1 million
transport services, then you will most likely have 150000 of those services
(i.e. 15% of total) requiring unavailability measurements. Assuming 70% of
those services are p2p, then 105000 p2p services require SES/UAS measurement
on the MEP functions located in the UNI-N ports in e.g. NTU and MTU devices.
For the multi-operator transport service subset (about 10%, i.e. 10500)
there will also be SES/UAS measurements on the E-NNI ports in intercarrier
gateway nodes (S-PEs). But I would expect that also on these E-NNIs, there
will be up to 15% of the services requiring SES/UAS measurement support.

45000 (i.e. 30% of the 150000) mp2mp/rmp services (TE-VLANs) require SES/UAS
measurement in ETH MEP functions on the I-NNI ports in PE nodes. And for the
4500 (10% of 45000) multi-operator mp2mp/rmp services, E-NNI ports on
intercarrier gateway nodes will have to support SES/UAS measurement in ETH
MEP functions.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 6 februari 2009 20:00
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP

Availability is a key metric/objective for *all* services (more important
than any general PM metric/objective), but is this not dependent on
measuring SES (assuming the unavailable state entry criteria is still 10
consecutive SES)?  So if wants wants to measure unavailability of all LSPs
does this then not mean a measurement of SES on all LSPs is required?

regards, Neil

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 9 Feb 2009 06:46:35 -0600

Maarten,

	You apparently missed my mention of the "mix"...

--
Eric  

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, February 09, 2009 2:35 AM
To: Eric Gray; 'Ben Niven-Jenkins'
Cc: [email-masked]
Subject: RE: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

Eric,

LSPs are providing the tunnel connections in the MPLS-TP network.
Tunnels
carry aggregates of transport service connections (PWs, VPLSs). In a
well
designed network, the number of tunnels will be much smaller then the
number
of transport service connections.

As an example, in a network with 5000 metro edge offices which are
partitioned into 100 metro domains, each having 50 metro edge nodes, you
will have:
- 4 tunnels terminating in a metro edge node (two protected pairs of
tunnels), which connect each metro edge node with one of the two metro
core
nodes (case of hub&spoke metro); this number will increase a bit when
the
metro domain has a partial mesh of tunnels
- 98 (49 protected pairs of) metro tunnels terminating in a metro core
node
per metro domain
- 98 (49 protected pairs of) core tunnels terminating in a metro core
node
for the core domain.
There are as such not too many tunnels per interface port to support, so
it
should be possible to support 100% tunnel (i.e. LSP) monitoring. I.e. by
default the "knob" could be "on".

The large number of connections (millions) are to be found in the
MPLS-TP
MS-PW and VPLS (i.e. ETH) layers. In those transport service layers it
is
important to support SES/UAS measurement to a subset of those PWs/VPLSs.
By
default the "knob" will be "off". Especially as this pro-active PM is a
service element which only a subset of services will require.

The smallest number of connections are to be found in the transmission
media
section layer (e.g. MPLS-TP Section or ETH Section). I would expect
SES/UAS
measurement by default to be "on".

The MPLS-TP PW MEP (like the ETH MEP) function today will have support
of
packet loss measurement as a configurable feature. The MPLS-TP LSP MEP
function will also have such packet loss measurement as a configurable
feature.

Regards,
Maarten

-----Original Message-----

Ben,

measurement

	We also feel that it is worth a note to indicate that it is
likely
that SES/UAS measurement will only apply to a subset of LSPs - if it is
used
at all - and this in turn argues for a default position of the "knob" to
be
"off." 

	I imagine in MIB-ese, that will mean that a MIB entry would only
exist for an LSP where this measurement is enabled.
This is very similar to how maintenance points are configured for
Ethernet
devices.

--
Eric

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Friday, February 06, 2009 12:47 PM
To: Eric Gray; Lam, Hing-Kam (Kam); Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

Eric,

Thanks
Ben

required

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 9 Feb 2009 07:17:05 -0600

Maarten,

	You're assuming that LSPs are only used for transport of MPLS-TP
tunnels, just because they might be.  Don't you think that you might 
be getting ahead of your self?

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, February 09, 2009 3:03 AM
To: [email-masked]; [email-masked];
[email-masked]; Eric Gray; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Performance monitoring & MPLS-TP
Importance: High

Neil,

G.7710 describes the processing steps to get to available time and
unavailable time for both circuit and packet technologies. 10
consecutive
SES or non-SES seconds will change the status available=>unavailable,
unavailable=>available time.

But for PWs/VPLSs, you must restrict your unavailability measurements to
a
subset; i.e. to the subset of PWs/VPLSs for which the SLA requires
pro-active Performance Monitoring. When your network supports e.g. 1
million
transport services, then you will most likely have 150000 of those
services
(i.e. 15% of total) requiring unavailability measurements. Assuming 70%
of
those services are p2p, then 105000 p2p services require SES/UAS
measurement
on the MEP functions located in the UNI-N ports in e.g. NTU and MTU
devices.
For the multi-operator transport service subset (about 10%, i.e. 10500)
there will also be SES/UAS measurements on the E-NNI ports in
intercarrier
gateway nodes (S-PEs). But I would expect that also on these E-NNIs,
there
will be up to 15% of the services requiring SES/UAS measurement support.

45000 (i.e. 30% of the 150000) mp2mp/rmp services (TE-VLANs) require
SES/UAS
measurement in ETH MEP functions on the I-NNI ports in PE nodes. And for
the
4500 (10% of 45000) multi-operator mp2mp/rmp services, E-NNI ports on
intercarrier gateway nodes will have to support SES/UAS measurement in
ETH
MEP functions.

Regards,
Maarten

-----Original Message-----

important
consecutive SES)?  So if wants wants to measure unavailability of all
LSPs

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Feb 2009 08:28:51 +0100

Eric,

My assumption is that in a MPLS-TP network the 
- transport service layer network is implemented by either ETH and MPLS-TP
PW, or by just ETH 
- transport tunnel layer netowrk is implemented by MPLS-TP LSP
- transmission media section layer network is implemented by either MPLS-TP
Section LSP, or by ETH Section
- transmission media physical media layer network is implemented by ETY, and
optionally by OTN, SDH.

For the case of a Carrier-Carrier application, a tunnel LSP of carrier A is
carried as a service instance in the carrier B network.

Tunnel LSPs are thus used to carry VLANs (VPLSs) and PWs, plus tunnel LSPs
of another carrier.
Section LSPs are used to carry either tunnel LSPs, or VLANs (VPLSs) and PWs.

It is important for the design of MPLS-TP equipment to be specific with
respect to the layer stack, as UNI-N, I-NNI and E-NNI ports must be able to
support the right signals.

If you have the opinion that my layer stack and client/server relations are
not correct, then please describe what you believe is the correct layer
stack and client/server relations in a MPLS-TP network.

Regards,
Maarten

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: maandag 9 februari 2009 14:17
To: Maarten Vissers; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Performance monitoring & MPLS-TP

Maarten,

	You're assuming that LSPs are only used for transport of MPLS-TP
tunnels, just because they might be.  Don't you think that you might be
getting ahead of your self?

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, February 09, 2009 3:03 AM
To: [email-masked]; [email-masked];

Neil,

Regards,
Maarten

-----Original Message-----

regards, Neil

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 10 Feb 2009 04:45:32 -0600

Maarten,

	In a context of transport applications, where MPLS-TP appears in
at least one place in the stack (and with reservations about
terminology),
this looks like a good example of how an MPLS-TP network might work.  I 
believe there are (possibly many) other options - for example, there is
at least one proposal for another way to provide what you're calling the
"transport service layer network" below.

	At issue is the possibility that transport applications of this
sort might be carried over an infrastructure already in use for purposes
of transporting IP services of a variety of types, possibly including
use of MPLS LSPs - to which transport-style availability monitoring does
not (and most likely should not) apply.

	It seems likely that you're considering non-MPLS-TP LSPs as out
of
scope in this discussion, but it would appear (to me at least) that this
was not the case for all parties in the discussion initially.  You came
into the discussion rather late, so - if that is what you are assuming
about the scope of the discussion, then perhaps you need to explicitly
say so.

	If that is not what you are assuming about the scope of the
current
discussion, then the description below is far from complete.

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2009 2:29 AM
To: Eric Gray; [email-masked]; [email-masked];

Eric,

My assumption is that in a MPLS-TP network the 
- transport service layer network is implemented by either ETH and
MPLS-TP
PW, or by just ETH 
- transport tunnel layer netowrk is implemented by MPLS-TP LSP
- transmission media section layer network is implemented by either
MPLS-TP
Section LSP, or by ETH Section
- transmission media physical media layer network is implemented by ETY,
and
optionally by OTN, SDH.

For the case of a Carrier-Carrier application, a tunnel LSP of carrier A
is
carried as a service instance in the carrier B network.

Tunnel LSPs are thus used to carry VLANs (VPLSs) and PWs, plus tunnel
LSPs
of another carrier.
Section LSPs are used to carry either tunnel LSPs, or VLANs (VPLSs) and
PWs.

It is important for the design of MPLS-TP equipment to be specific with
respect to the layer stack, as UNI-N, I-NNI and E-NNI ports must be able
to
support the right signals.

If you have the opinion that my layer stack and client/server relations
are
not correct, then please describe what you believe is the correct layer
stack and client/server relations in a MPLS-TP network.

Regards,
Maarten

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: maandag 9 februari 2009 14:17
To: Maarten Vissers; [email-masked]; [email-masked];

Maarten,

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, February 09, 2009 3:03 AM
To: [email-masked]; [email-masked];

Neil,

Regards,
Maarten

-----Original Message-----

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 12 Feb 2009 16:00:13 +0100

Eric,

> It seems likely that you're considering non-MPLS-TP LSPs as out of scope
in this discussion

	I indeed assume that use of non-MPLS-TP LSPs to be out of scope of a
MPLS-TP network.

	In my considerations, there is only an MPLS-TP network if the
section, transport tunnel (path) and transport service (channel) layers are
true transport layers (i.e. MPLS-TP and ETH layers).

	In order to guarantee in future that it will possible to simply
interconnect two MPLS-TP NNI ports with each other and have then
interoperability (in a similar manner as we have today when interconnecting
two SDH NNI ports or two OTN NNI ports), it is necessary to standardize the
layer stack and NNI signal formats, the UNI-N and NNI port types and the
functionality of each of those UNI-N and NNI ports. 

	The revised version of G.8112 will specify the MPLS-TP NNI signal
formats, and as editor of this recommendation I am trying to get this layer
stack and associated NNI signal formats understood. The sooner we get to
this point, the sooner I will be able to progress the revision of G.8112 via
correspondence.

	In parallel, I am trying to develop the associated NNI and UNI-N
port functionalities so that we can document this in the revised G.8121 and
provide guidance to the market. My draft document "Types and characteristics
of MPLS-TP based PTN equipment" is a first attempt of defining these NNI and
UNI-N port functionalities for an MPLS-TP network. This document starts with
an overview of the layer stack, the partitioning of a carrier network into
aggregations domains and the operation of such multi-layer network. This
provides the starting point for the NNI signal format definition and the
UNI-N and NNI port types/functionality.

	The equivalent "Types and characteristics of Ethernet VLAN based PTN
equipment" document provides similar NNI and UNI-N port functionalities for
an Ethernet VLAN network. As we have most Ethernet VLAN functionality
available at the moment, I was able to give a much more complete description
of an Ethernet VLAN based PTN, its NNI signal formats and UNI-N and NNI port
types than I can present today for the MPLS-TP. MPLS-TP must be able to
support the same set of services and provide the same set of capabilities,
so we can use this ethernet alternative as reference for our MPLS-TP
definitions.

	The Ethernet VLAN based PTN network is also less complex then the
MPLS-TP based PTN as the ETH layer is used for all three roles: transport
service/channel, transport tunnel/path and section. Management Plane for
each ETH instance is the same and also the optional contorl plane for the
ETH instances (transport service, transport tunnel) are the same.

	MPLS-TP seems to get three different layers involved: ETH (transport
service, section), MS-PW (transport service) and LSP (transport path,
section). Management plane for these three layers can be made very similar
(my proposals), or could become unnecessary different (current direction).
Control planes for these three layers seems to be different: GMPLS for ETH
and MPLS-TP LSP and LDP+ for MPLS-TP MS-PW. But we could make those similar
if we decide to use GMPLS also for the MPLS-TP MS-PW layer. 

	From an equipment and operational perspective such differences
increase complexity of the MPLS-TP solution. 

	Those differences also increases the complexity of the emerging
multi-technology PTN, in which access and metro domains are typically
Ethernet VLAN based and in which core domains are typically MPLS and in
future MPLS-TP based. If this would indeed happen, then I expect that it is
just a matter of time before Ethernet VLAN based PTN switches are scaled up
to a level in which they can be used as metro core and core switches,
replacing the MPLS(-TP) equivalent nodes. So, let's make sure this latter is
not necessary.

Regards,
Maarten

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: dinsdag 10 februari 2009 11:46
To: Maarten Vissers; [email-masked]; [email-masked];

Maarten,

	In a context of transport applications, where MPLS-TP appears in at
least one place in the stack (and with reservations about terminology), this
looks like a good example of how an MPLS-TP network might work.  I believe
there are (possibly many) other options - for example, there is at least one
proposal for another way to provide what you're calling the "transport
service layer network" below.

	At issue is the possibility that transport applications of this sort
might be carried over an infrastructure already in use for purposes of
transporting IP services of a variety of types, possibly including use of
MPLS LSPs - to which transport-style availability monitoring does not (and
most likely should not) apply.

	It seems likely that you're considering non-MPLS-TP LSPs as out of
scope in this discussion, but it would appear (to me at least) that this was
not the case for all parties in the discussion initially.  You came into the
discussion rather late, so - if that is what you are assuming about the
scope of the discussion, then perhaps you need to explicitly say so.

	If that is not what you are assuming about the scope of the current
discussion, then the description below is far from complete.

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 10, 2009 2:29 AM
To: Eric Gray; [email-masked]; [email-masked];

Eric,

Regards,
Maarten

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: maandag 9 februari 2009 14:17
To: Maarten Vissers; [email-masked]; [email-masked];

Maarten,

--
Eric 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, February 09, 2009 3:03 AM
To: [email-masked]; [email-masked];

Neil,

Regards,
Maarten

-----Original Message-----

regards, Neil