Subject: [mpls-tp] OAM requirements discussions in Geneva

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Dec 2008 14:53:51 -0000

Hi,

Another topic of conversation in Geneva was OAM. We tried to squeeze some of 
the apparent requirements to find out what feature/functional requirements 
were hiding underneath. We also tried to push the suggested solutions to see 
what was really driving them.

I took a few scribbled notes and arrived at the following list of 
requirements. These are not intended to be a complete set, and may overlap 
with those already in the OAM requirements draft.

Could the editors of the OAM requirements draft please look at incorporating 
these into the draft. If there is overlap, the addition of some of the text 
here as clarification might help.

Thanks,
Adrian

===

What do we need to run OAM on?
- e2e LSP
- data link
- between a pair of MEPs on an LSP
- between a MEP and a MIP on an LSP where the
  MEP and MIP are in the same ME

What defines the location of MEPs?
- MEPs are at the end points of MEs.
- A ME applies to a specific LSP
- MEs are typically driven by topological/management features
  - protection domains
  - sub-network boundaries
  - rings
  - but also e2e LSPs, aggregation tunnels, etc.

How dynamic is the definition of an ME? I.e., given an LSP, how often will 
MEPs be defined?
- According to the previous paragraph, this is mainly a
  maintenance/planning activity for the network such that
  the MEs on an LSP are inherited from the
  topology/management of the network that the LSP
  crosses.
- A very slow dynamic also needs to be supported so
  that the MEs can be changed underneath an LSP as
  a planning function
- A more rapid dynamic change of MEs does not need
  to be supported.

We should support hitless imposition of new and removal of old  MEs.

OAM must provide fault detection that enables 60ms (total) switch protection 
on any LSP
This is generally assumed to mean 10ms fault detection, to allow 50ms switch 
time.

There is no requirement to apply fault detection OAM per LSP *if* it can be 
achieved through either LSP aggregation or lower layer OAM.
That is, faults must be informed to each LSP affected by the LSP, but the 
mechanism for detection does not need to be OAM run on each LSP.

Performance measurement capabilities are required per LSP in any ME on the 
ME
It is important to clarify what is meant by performance measurement!
- Packet counts
  Mechanisms that count the number of OAM packets lost
  are probably not very helpful as they don't tell us anything
  about the data loss/delivery. In fact, the use of OAM in
  that way might very well change the performance of the
  LSP.
  Thus, we need "start counting" and "end counting" messages.
    - These must be sent interleaved in the data to ensure
       in-order delivery with the data that is being counted.
- Delay can only be measured using OAM messages
- Bandwidth verification
   You can test and report current utilisation
      - behavior is like packet counting
   You cannot test the limits of the available bandwidth in
   a non-destructive way so the LSP must be out of service
- Performance measurement is off by default
- There is no requirement to do performance measurement
   of all LSPs in the network at the same time

For some purposes we want fate sharing between OAM messages and traffic
This is important for "integrity checking/monitoring". Here the OAM and data 
must follow the same path. This includes not just hops (i.e. links) but also 
the precise forwarding path (i.e. same LFIB entries). This can only be 
achieved if the OAM shares the same top label as the data.
Other uses of OAM (e.g. quality of delivery) can only provide some 
statistical measure of fate sharing as we cannot be sure that OAM packets 
are treated identically to data packets. Furthermore, even in the integrity 
check case, it is possible to see false positives if OAM packets are treated 
differently from data packets (perhaps because of their size). False 
negatives will not arise because an integrity failure will necessarily 
impact all packets.

An important operational requirement is for an operator inspecting an LSR to 
be able to determine which LSPs traverse that LSR. For the sake of this 
discussion, the LSPs we are interested in are the outer layer LSPs before 
applying any OAM techniques. Thus, we mean either the e2e LSPs or the top 
level aggregation tunnel that carries other LSPs.
This requirement is the issue that has led to an apparent requirement for 
1:1 encapsulation of LSPs within TC-LSPs. It was noted in discussion, 
however, that a variety of technical solutions (both management plane and 
control plane) might be applied to meet this requirement without forcing a 
1:1 solution.

When you reserve b/w for an LSP you must reserve enough b/w for all the OAM 
that MIGHT be used on the LSP

Performance monitoring needs to be applied per class of service 

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

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 17 Dec 2008 11:59:20 +0100

Adrian,

thanks for these inputs. Please see in-line.
regards,

-m

Adrian Farrel a écrit :
> Hi,
> 
> Another topic of conversation in Geneva was OAM. We tried to squeeze 
> some of the apparent requirements to find out what feature/functional 
> requirements were hiding underneath. We also tried to push the suggested 
> solutions to see what was really driving them.
> 
> requirements. These are not intended to be a complete set, and may 
> overlap with those already in the OAM requirements draft.
> 
> Could the editors of the OAM requirements draft please look at 
> incorporating these into the draft. If there is overlap, the addition of 
> some of the text here as clarification might help.
> 
> Thanks,
> Adrian
> 
> ===
> 
all these are covered.
    OAM functions MUST be able to be used for PWs, LSPs and Sections.
    Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
    run on each LSP, regardless of the label stack depth.

    It MUST be possible to perform OAM functions on a per domain
    basis and across multiple domains. More generally it MUST be possible
    to perform OAM functions between any two switching elements of a PW
    or of a LSP.
>  - but also e2e LSPs, aggregation tunnels, etc.
are these reqs?
I would tend to think that this is explanatory text that would
better fit in the oam framework doc. no?

> 
> How dynamic is the definition of an ME? I.e., given an LSP, how often 
> will MEPs be defined?
this is not covered in the draft, currently.
will use your thoughts/text
> 
> OAM must provide fault detection that enables 60ms (total) switch 
> protection on any LSP
> This is generally assumed to mean 10ms fault detection, to allow 50ms 
> switch time.
this is not covered in the draft but there is a place-holder for a
performance/scalability section
> 
> There is no requirement to apply fault detection OAM per LSP *if* it can 
> be achieved through either LSP aggregation or lower layer OAM.
> That is, faults must be informed to each LSP affected by the LSP, but 
> the mechanism for detection does not need to be OAM run on each LSP.
The draft currently states:
    This document does not mandate the use of a particular OAM function,
    however, it is RECOMMENDED that connectivity and continuity
    verification is performed on every Maintenance Entity in order to
    reliably detect connectivity defects.

    Moreover, the use of OAM functions SHOULD be optional for the service
    provider or network operator. A network operator or service provider
    SHOULD be able to choose which OAM functions to use and which
    Maintenance Entities to apply them to.

clarification text could be added in the perf/scal section.

> 
> Performance measurement capabilities are required per LSP in any ME on 
> the ME
will use text for clarifications if needed

> This is important for "integrity checking/monitoring". Here the OAM and 
> data must follow the same path. This includes not just hops (i.e. links) 
> but also the precise forwarding path (i.e. same LFIB entries). This can 
> only be achieved if the OAM shares the same top label as the data.
I fully concur.
By the way, as a consequence of stacking in the context of PST
the monitoring of the PST will not reflect the exact same thing
as if monitoring was done on the lsp itself.

> statistical measure of fate sharing as we cannot be sure that OAM 
> packets are treated identically to data packets. Furthermore, even in 
> the integrity check case, it is possible to see false positives if OAM 
> packets are treated differently from data packets (perhaps because of 
> their size). False negatives will not arise because an integrity failure 
> will necessarily impact all packets.
I am not sure to understand this paragraph.

> 
> An important operational requirement is for an operator inspecting an 
> LSR to be able to determine which LSPs traverse that LSR. For the sake 
> of this discussion, the LSPs we are interested in are the outer layer 
> LSPs before applying any OAM techniques. Thus, we mean either the e2e 
> LSPs or the top level aggregation tunnel that carries other LSPs.
> This requirement is the issue that has led to an apparent requirement 
> for 1:1 encapsulation of LSPs within TC-LSPs. It was noted in 
> discussion, however, that a variety of technical solutions (both 
> management plane and control plane) might be applied to meet this 
> requirement without forcing a 1:1 solution.
I do not quite catch the determination of which LSPs traverse which LSRs
discussion point and do not really see how it relates to PSTs. Thanks.

I understood there was a will to provide to providers with the
capability to monitor e.g. LSPs on a sub-path and do this on a per LSP
basis. 1:1 stacking seemed a solution to this.
As I see it, the 1:1 has the advantage of providing per LSP monitoring
results, the 1:N has the advantage of requiring a single entity to
monitor N sub-LSPs.
Anyway, I believe 1:1 or 1:N is an operational decision and so largely
outside the scope of the oam-reqs darft.

> 
> When you reserve b/w for an LSP you must reserve enough b/w for all the 
> OAM that MIGHT be used on the LSP
or should we ensure that OAM messages sent in a LSP do not start causing
packet loss in that LSP?

> Performance monitoring needs to be applied per class of service
ok

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Dec 2008 13:48:19 -0000

Hi Martin,

Snipped somewhat...

> better fit in the oam framework doc. no?

I think you are right.

>    reliably detect connectivity defects.

Well, you can tell that I haven't reviewed your draft!

RECCOMENDED gives me two problems:

1. I think your draft should be setting the requirements for MPLS-TP 
solutions, not for deployments/implementations.
Thus, your draft should say...
  ...it is RECOMMENDED that MPLS-TP enables connectivity and ...
  ... to be performed...

2. From a deployment point of view, RECOMMEND is far too strong. It is 
clearly entirely an operational choice and, in fact, a ME may exist for 
performance and diagnostic purposes only. Running continuity verification on 
nested MEs would be excessive. See the next paragraph.

> as if monitoring was done on the lsp itself.

This is debatable.

The conclusion that Italo drove me to last week is that when a PST is 
installed for OAM, it is installed when the LSP is set up not when OAM is 
enabled. Thus the data traffic always uses the PST label stack and the OAM 
and data have identical label stacks all the time.

But maybe you are making the point that end-to-end OAM can be achieved 
without using a PST. This is true. But in this case, there is still no 
difference in behavior between OAM and data packets because neither of them 
traverses a PST.

>> are treated identically to data packets. Furthermore, even in the 
>> integrity check case, it is possible to see false positives if OAM 

OK.

There are three points in the paragraph.

1. OAM packets, even with identical label stacks to data packets, will 
possibly receive different processing within the network. For example, data 
packets are likely to be larger than OAM packets and this is likely to 
change their chance of being dropped. In practice, we cannot say that OAM 
packets and data packets have the same qualatitive fate sharing. Thus, if we 
try to use OAM packets to actively monitor quality of delivery, we may get 
false values.

2. False positives may arise during integrity checking. That is, the OAM may 
report a connection failure when one does not exist. This might arise if OAM 
packets are dropped within the network, but data packets are delivered. In a 
congested network, packets may be dropped for a variety of reasons, and it 
could be (perhaps just by chance) that the OAM packets are dropped when the 
data gets through.

3. False negatives cannot arrise during integrity checking. That is, OAM 
cannot report that a connection is OK when the connection has actually 
failed. This is because the OAM does follow exactly the same forwarding path 
as the data.

>> An important operational requirement is for an operator inspecting an LSR 
>> to be able to determine which LSPs traverse that LSR. For the sake of 
>> this discussion, the LSPs we are interested in are the outer layer LSPs 
>> before applying any OAM techniques. Thus, we mean either the e2e LSPs or 
>> the top level aggregation tunnel that carries other LSPs.
>> control plane) might be applied to meet this requirement without forcing 
>> a 1:1 solution.
>
> discussion point and do not really see how it relates to PSTs.

This was a requirement stated by Italo and confirmed by Andrea Digiglio 
(Telecom Iitalia).

The requirement is that an operator "visting" an LSR in the middle of the 
network needs to be able to determine which connections are supported by the 
LSR, and more precisely, which connections are supported on any interface. 
This knowledge allows the operator to perform maintenance operations in the 
knowledge of what traffic will be disrupted.

For this discussion, a "connection" is an end-to-end connection, or an 
aggregation tunnel used for network scaling (i.e. a hierarchical PST). But a 
significant point is that if OAM is achieved by using a PST, this 
hierarchical LSP must not get in the way of the operator seeing the 
connections.

Italo had a solution in mind that was driving him to use a 1:1 relationship 
between OAM PST (be called it TC) and monitored LSP. I can see why that 
solution arose for him.

It turns out that we can think of several solutions (control plane and 
management plane) that allow the OAM PST to support multiple monitored LSPs 
at the same time, thus preserving the functional requirement while allowing 
OAM scaling benefits.

Anyway...
The net result is that:
- There is no requirement for a 1:1 relationship between
   OAM mechanism and monitored LSP
- There is a requirement to be able to find out the
   connections traversing an LSR
 - There is a desire to provide OAM scaling techniques

> basis. 1:1 stacking seemed a solution to this.

True it is a solution.
I think we want to allow 1:1
I think it is important not to prohibit 1:n

> results, the 1:N has the advantage of requiring a single entity to

It is unclear to me what is meant by "per-LSP" monitoring, and we spent some 
time trying to uncover the real requirement.

In terms of connectivity and continuity monitoring over a fragment of a path 
(an LSP segment). If (not that this is a big "if") the solution applied is 
the use of a PST as a monitoring entity, then monitoring the PST achieves 
the same function of monitoring a single LSP even if the PST carries more 
than one LSP. Further, it scales better in the case of more than one LSP 
being measured.

If the "per-LSP monitoring" means something like performance monitoring, 
then it should be observed that the role of OAM is small (turning monitoring 
on and off, reporting monitored figures). This can be achieved using a 1:n 
PST or even out-of-band messaging so long as the monitored LSP is 
identified.

Thus, we struggled to find the requirement for per-LSP monitoring, and so we 
could not find any requirement to mandate not offering 1:n OAM PSTs.

> outside the scope of the oam-reqs darft.

I would tend to agree.
But there was a push to make 1:1 a requirement and 1:n not allowed.

> or should we ensure that OAM messages sent in a LSP do not start causing

I think this is the same statement.

We cannot specify that an LSR must treat the OAM packets differently from 
the data packets (for example, making sure that the OAM is dropped in 
preference to the data) because that contradicts the fate sharing rules. And 
it might be hard for the LSR to tell which packets are data and which are 
OAM.

So, in order to ensure that the OAM packets do not cause disruption to the 
data, we must ensure that the packets are expected, and that there are 
sufficient buffers to handle them.

Cheers,
Adrian

---

From: "Greg Mirsky" <[email-masked]>
Date: Wed, 17 Dec 2008 10:36:40 -0500

Hi Adrian,
I'd ask about OAM control and control messages. You've mentioned that
control of OAM functions, at least for packet counting, must be sent over
the data path.

>      in-order delivery with the data that is being counted.

Unless we require that action upon such OAM control is instantaneous and
takes effect on the next immediate packet I don't think that OAM control
must follow data path. If precise counting is required it perhaps can be
achieved actually scheduling certain actions.
I think that control of OAM is not necessarily done over the the Data Plane.

Regards,
Greg

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Dec 2008 16:34:13 -0000

Hi Greg,

I must say that I had the same view as you, but it was put to me that the 
loss in accuracy caused by out-of-band messages might be extremely 
significant.

I have no idea what sort of level of accuracy is required by operators 
(attempts by Loa to get this defined didn't seem to make much headway). It 
is clear to me that if some relatively high level of accuracy is required, 
the control must be interleaved in the data. And it is also clear that if 
complete accuracy is required the only options are to number the packets 
(which would be a significant change) or to interleave control with data and 
require ordered processing.

Since we are already talking of ways to interleave control with data, it is 
only a matter of the ordered processing. This could be something that 
different vendors offer in different ways including various levels of 
processing. But I note that counting is likely to be in hardware, and that 
the control messages to start/stop counting could be structured to be 
processable in hardware.

Cheers,
Adrian
----- Original Message ----- 
From: "Greg Mirsky" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 17, 2008 3:36 PM
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

>> the

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 17 Dec 2008 12:08:39 -0500

Greg/Adrian,

opinion from one of the persons responsible for making the headway in
defining this...:-

The intent is to model the LM based on Y.1731 where
in-profile/in-service data frame Rx/Tx
stats are exchanged between 2 MEPs over a period of time (Using LMM/LMR
type of OAM frames) 
to calculate the FL and FLR. The start/stop in-band sentinel frames is
not necessary as
LMM/LMR OAM frames indirectly serves the same purpose.

Not sure where the LM based on OAM pkt loss proposal comes from - and
certainly agree that
to be inadequate for the same reasons you have described below.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Wednesday, December 17, 2008 11:34 AM
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Hi Greg,

I must say that I had the same view as you, but it was put to me that
the loss in accuracy caused by out-of-band messages might be extremely
significant.

I have no idea what sort of level of accuracy is required by operators
(attempts by Loa to get this defined didn't seem to make much headway).
It is clear to me that if some relatively high level of accuracy is
required, the control must be interleaved in the data. And it is also
clear that if complete accuracy is required the only options are to
number the packets (which would be a significant change) or to
interleave control with data and require ordered processing.

Since we are already talking of ways to interleave control with data, it
is only a matter of the ordered processing. This could be something that
different vendors offer in different ways including various levels of
processing. But I note that counting is likely to be in hardware, and
that the control messages to start/stop counting could be structured to
be processable in hardware.

Cheers,
Adrian

---

From: "Greg Mirsky" <[email-masked]>
Date: Wed, 17 Dec 2008 14:47:00 -0500

Hi Adrian,
if these are requirements put forward by parties outside of IETF then so be
it. You know of work being done in
draft-takacs-ccamp-oam-configuration-fwk-01.txt. And, as I understand it,
RSVP signaling might be used not only to configure ME but to control its
operation (i.e. stop/start CC). Given this "in-band OAM PM control"
requirement, should it be referenced in the above mentioned draft? And
somewhat broader question "Can OAM control be both in- and out-band or only
in-band?"

Regards,
Greg

On Wed, Dec 17, 2008 at 11:34 AM, Adrian Farrel <[email-masked]> wrote:

> ----- Original Message ----- From: "Greg Mirsky" <[email-masked]>

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 00:42:40 -0000

Some minor remarks...snipped to those I want to comment on:
Adrian said 17 December 2008 13:48

> Well, you can tell that I haven't reviewed your draft!
NH=> I often wonder if folks recognise the differences between
continuity check (CC) and connectivity check (CV)?  I introduced the CV
definition a long time ago (in Y.1710/1711) on purpose because I
specifically wanted to differentiate the ability to check correct
(connection) connectivity (ie detecting a case of traffic/OAM NOT going
to the right place) from (the old ATM based) CC check....which had no SA
base (in the CC OAM pkts) and simply checked that (CC pkts) were
arriving at the intended destination....which is not good enough.

As a general rule we should use CV over CC, and CV OAM pkts should
contain the SA of the the connection....at least in co-ps mode
technologies based on label-swapping.

> Running continuity verification on nested MEs would be 
> excessive. See the next paragraph.
NH=> Absolutely.  But nested MEs are excessive period.  At least one
person (not an operator I hasten to add) thinks it a great idea to have
shed-loads of nested ME levels (as sublayers)....and worse, have
NNIs.....and even worse, NNIs between different mode technologies.  Not
sure where this person gets his ideas from but I am pretty sure it is
NOT operators.....and at least not anyone I know in BT.

> >> For some purposes we want fate sharing between OAM messages and 
> >> traffic This is important for "integrity 
> checking/monitoring". Here 
> >> the OAM and data must follow the same path. This includes not just 
> >> hops (i.e. links) but also the precise forwarding path (i.e. same 
> >> LFIB entries). This can only be achieved if the OAM shares 
> the same top label as the data.
> >
> > I fully concur.
NH=> So do I.  But OAM has a config/processing/collection cost....and
this include its intrinsic *reliability*.  This is why I always make a
key distinction between (i) always-on defect detection/handling OAM and
(ii) on-demand investigative or PM OAM...the former MUST be as
sparse/simple (inc config) as possible for the network mode being
considered.  There is also NOT a general OAM technique that can be
applied to all network modes.

> >> the integrity check case, it is possible to see false positives if 
> >> OAM packets are treated differently from data packets (perhaps 
> >> because of their size). False negatives will not arise because an 
> >> integrity failure will necessarily impact all packets.
> >
> 1. OAM packets, even with identical label stacks to data 
> packets, will possibly receive different processing within 
> the network. For example, data packets are likely to be 
> larger than OAM packets and this is likely to change their 
> chance of being dropped. In practice, we cannot say that OAM 
> packets and data packets have the same qualatitive fate 
> sharing. Thus, if we try to use OAM packets to actively 
> monitor quality of delivery, we may get false values.
NH=> True as of now...but see next point.
> 
> 2. False positives may arise during integrity checking. That 
> is, the OAM may report a connection failure when one does not 
> exist. This might arise if OAM packets are dropped within the 
> network, but data packets are delivered. In a congested 
> network, packets may be dropped for a variety of reasons, and 
> it could be (perhaps just by chance) that the OAM packets are 
> dropped when the data gets through.
NH=> Yes IFF one subscribes to the flawed view that a single connection
can have multiple QoS levels.  A connection MUST preserve symbol
ordering, and a corollary of this is that a connection MUST only have a
single QoS classification.  Thus OAM and traffic in a connection SHOULD
have the same 'QoS weighting' in *that* connection
> 
> 3. False negatives cannot arrise during integrity checking. 
> That is, OAM cannot report that a connection is OK when the 
> connection has actually failed. This is because the OAM does 
> follow exactly the same forwarding path as the data.
NH=> There is the case of course of unintended replication and leaking.
So whilst a CV check of connection A-B looks fine, its traffic could be
replicated and leaking into some other X-Y connection....but a CV check
(on the SA of OAM pkts arriving at Y) would detect this and diagnose the
offending connection (as sourced from A).

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 08:32:33 +0100

Himanshu,

The most important frame loss measurement in Y.1731 Ethernet OAM is included
in the ETH CCM frames. This pro-active loss measurement provided by CCM is
used to compute the DEGraged defect (dDEG) and to compute the performance
monitoring parameters (S)ES, BBC and UAT/UAS. Those latter PM parameters are
used check the service level agreements.

The LMM/LMR based frame loss measurement is an on-demand loss mesasurement
that can be used to take snapshots of the frame loss in connections without
pro-active monitoring.

Customers will be able to monitor the performance provided by the transport
network by measuring the performance of the service from "UNI-C to UNI-C".
E.g. an E-LINE service supported by a MS-PW in the transport network will be
monitored by the customer using ETH MEP functions on the UNI-C ports, and by
the network using MS-PW MEP functions on the UNI-N ports.

If these two performance measurements (i.e. (S)ES/BBC/UAT based) do not
result in very similar numbers, then this may result in a SLA conflict
between both parties. Accurate performance measurements can prevent such
conflicts to occur.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shah, Himanshu
Sent: woensdag 17 december 2008 18:09
To: Adrian Farrel; Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Greg/Adrian,

The intent is to model the LM based on Y.1731 where in-profile/in-service
data frame Rx/Tx stats are exchanged between 2 MEPs over a period of time
(Using LMM/LMR type of OAM frames) to calculate the FL and FLR. The
start/stop in-band sentinel frames is not necessary as LMM/LMR OAM frames
indirectly serves the same purpose.

Not sure where the LM based on OAM pkt loss proposal comes from - and
certainly agree that to be inadequate for the same reasons you have
described below.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Wednesday, December 17, 2008 11:34 AM
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Hi Greg,

I have no idea what sort of level of accuracy is required by operators
(attempts by Loa to get this defined didn't seem to make much headway).
It is clear to me that if some relatively high level of accuracy is
required, the control must be interleaved in the data. And it is also clear
that if complete accuracy is required the only options are to number the
packets (which would be a significant change) or to interleave control with
data and require ordered processing.

Cheers,
Adrian
----- Original Message -----
From: "Greg Mirsky" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 17, 2008 3:36 PM
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

>>  Mechanisms that count the number of OAM packets lost  are probably 
>> not very helpful as they don't tell us anything  about the data 
>> loss/delivery. In fact, the use of OAM in  that way might very well 
>> change the performance of the  LSP.

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 10:24:22 -0000

Can I ask which operators want all this complex OAM, and esp the nested
TCM stuff?  Act/deact of *simple* defect detection/handling trail term
pt OAM (ie CV flow) in sync with signalling is defintely required, but
we have no requirements at all for lots of of nested TCM levels.
 
Please keep in mind this very simple point:  If a network requires lots
of OAM to be running to keep it operational then that network is already
broken and not fit for purpose.  Real world networks MUST operate such
that very little OAM is required for their normal day-day operation.  We
generally only want the more complex diagnostics OAM (in which I include
PM stuff) on a rare on-demand basis.
 
And to repeat an earlier point...we have no requirement whatsover for
interworking OAM (or any other DP/CP/MP components) between different
network modes/technologies which are not top-of-stack.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Greg Mirsky
	Sent: 17 December 2008 19:47
	To: Adrian Farrel
	Cc: [email-masked]
	Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

	Hi Adrian,
	if these are requirements put forward by parties outside of IETF
then so be it. You know of work being done in
draft-takacs-ccamp-oam-configuration-fwk-01.txt. And, as I understand
it, RSVP signaling might be used not only to configure ME but to control
its operation (i.e. stop/start CC). Given this "in-band OAM PM control"
requirement, should it be referenced in the above mentioned draft? And
somewhat broader question "Can OAM control be both in- and out-band or
only in-band?"
	
	Regards,
	Greg

	On Wed, Dec 17, 2008 at 11:34 AM, Adrian Farrel
<[email-masked]> wrote:

		Hi Greg,
		
		I must say that I had the same view as you, but it was
put to me that the loss in accuracy caused by out-of-band messages might
be extremely significant.
		
		I have no idea what sort of level of accuracy is
required by operators (attempts by Loa to get this defined didn't seem
to make much headway). It is clear to me that if some relatively high
level of accuracy is required, the control must be interleaved in the
data. And it is also clear that if complete accuracy is required the
only options are to number the packets (which would be a significant
change) or to interleave control with data and require ordered
processing.
		
		Since we are already talking of ways to interleave
control with data, it is only a matter of the ordered processing. This
could be something that different vendors offer in different ways
including various levels of processing. But I note that counting is
likely to be in hardware, and that the control messages to start/stop
counting could be structured to be processable in hardware.
		
		Cheers,
		Adrian
		----- Original Message ----- From: "Greg Mirsky"
<[email-masked]>
		To: "Adrian Farrel" <[email-masked]>
		Cc: <[email-masked]>
		Sent: Wednesday, December 17, 2008 3:36 PM
		Subject: Re: [mpls-tp] OAM requirements discussions in
Geneva 

			Hi Adrian,
			I'd ask about OAM control and control messages.
You've mentioned that
			control of OAM functions, at least for packet
counting, must be sent over
			the data path.

				Performance measurement capabilities are
required per LSP in any ME on the
				ME
				It is important to clarify what is meant
by performance measurement!
				- Packet counts
				 Mechanisms that count the number of OAM
packets lost
				 are probably not very helpful as they
don't tell us anything
				 about the data loss/delivery. In fact,
the use of OAM in
				 that way might very well change the
performance of the
				 LSP.
				 Thus, we need "start counting" and "end
counting" messages.
				 - These must be sent interleaved in the
data to ensure
				    in-order delivery with the data that
is being counted.

			Unless we require that action upon such OAM
control is instantaneous and
			takes effect on the next immediate packet I
don't think that OAM control
			must follow data path. If precise counting is
required it perhaps can be
			achieved actually scheduling certain actions.
			I think that control of OAM is not necessarily
done over the the Data Plane.
			
			Regards,
			Greg

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 18 Dec 2008 05:34:05 -0500

Marteen,

Agree.

While I was referring to on-demand mechanisms,
partly in response to "start/stop counting" discussions,
by no means at exclusion of pro-active tools.

regards,
himanshu

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thu 12/18/2008 2:32 AM
To: Shah, Himanshu; 'Adrian Farrel'; 'Greg Mirsky'
Cc: [email-masked]
Subject: RE: [mpls-tp] OAM requirements discussions in Geneva
 
Himanshu,

Regards,
Maarten

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

Greg/Adrian,

/himanshu

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

Hi Greg,

Cheers,
Adrian

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 18 Dec 2008 12:59:27 +0100

Adrian,

thanks for your answer.
please see in-line.

>> better fit in the oam framework doc. no?
cool :-)
> 
>>> There is no requirement to apply fault detection OAM per LSP *if* it 
>>> can be achieved through either LSP aggregation or lower layer OAM.
> performance and diagnostic purposes only. Running continuity 
> verification on nested MEs would be excessive. See the next paragraph.
I understand your two points.
>>> This is important for "integrity checking/monitoring". Here the OAM 
>>> and data must follow the same path. This includes not just hops (i.e. 
>>> links) but also the precise forwarding path (i.e. same LFIB entries). 
>>> This can only be achieved if the OAM shares the same top label as the 
>>> data.
>>
>> I fully concur.
> installed for OAM, it is installed when the LSP is set up not when OAM 
> is enabled. Thus the data traffic always uses the PST label stack and 
> the OAM and data have identical label stacks all the time.
true, but ... see below
> difference in behavior between OAM and data packets because neither of 
> them traverses a PST.
No I was making another point, but that is a side discussion ;-)
PSTs are used as a means to monitor sub-LSPs.
What will effectively be monitored is the PSTs while the original
objective was the monitoring of the sub-LSPs.
So the monitoring result differs from what would have been the
monitoring result in the original case.
Hope I was clear.

> possibly receive different processing within the network. For example, 
> data packets are likely to be larger than OAM packets and this is likely 
> to change their chance of being dropped. In practice, we cannot say that 
> OAM packets and data packets have the same qualatitive fate sharing. 
> Thus, if we try to use OAM packets to actively monitor quality of 
> delivery, we may get false values.
understood

> 
> 2. False positives may arise during integrity checking. That is, the OAM 
> may report a connection failure when one does not exist. This might 
> arise if OAM packets are dropped within the network, but data packets 
> are delivered. In a congested network, packets may be dropped for a 
> variety of reasons, and it could be (perhaps just by chance) that the 
> OAM packets are dropped when the data gets through.
true, but that is why actions are not taken at the first packet loss
In fact that is the message behind the sentence in the draft which says:
    OAM functions SHOULD continue to meet their objectives regardless of
    congestion conditions. See also ITU-T Y.1541 [4].
In essence, as I understand it, it says that the detection thresholds
should be set such that they upfront take into account various network
states.

> failed. This is because the OAM does follow exactly the same forwarding 
> path as the data.
> 
>>> LSR to be able to determine which LSPs traverse that LSR. For the 
>>> sake of this discussion, the LSPs we are interested in are the outer 
>>> layer LSPs before applying any OAM techniques. Thus, we mean either 
>>> the e2e LSPs or the top level aggregation tunnel that carries other 
>>> LSPs.
> The requirement is that an operator "visting" an LSR in the middle of 
> the network needs to be able to determine which connections are 
> supported by the LSR, and more precisely, which connections are 
> supported on any interface. This knowledge allows the operator to 
> perform maintenance operations in the knowledge of what traffic will be 
> disrupted.
I understand the requirement.
Was the way to get that info discussed (e.g. snmp, oam tool, sig, ...)?

> aggregation tunnel used for network scaling (i.e. a hierarchical PST). 
> But a significant point is that if OAM is achieved by using a PST, this 
> Italo had a solution in mind that was driving him to use a 1:1 
> relationship between OAM PST (be called it TC) and monitored LSP. I can 
> see why that solution arose for him.
> 
> management plane) that allow the OAM PST to support multiple monitored 
> LSPs at the same time, thus preserving the functional requirement while 
> allowing OAM scaling benefits.
and while letting the provider know what LSPs are in it?
> - There is a desire to provide OAM scaling techniques
ok, fine
> It is unclear to me what is meant by "per-LSP" monitoring, and we spent 
> some time trying to uncover the real requirement.
per-lsp = sending oam messages on each lsp
> 
> In terms of connectivity and continuity monitoring over a fragment of a 
> path (an LSP segment). If (not that this is a big "if") the solution 
> applied is the use of a PST as a monitoring entity, then monitoring the 
> PST achieves the same function of monitoring a single LSP even if the 
> PST carries more than one LSP. Further, it scales better in the case of 
> more than one LSP being measured.
agreed

> then it should be observed that the role of OAM is small (turning 
> monitoring on and off, reporting monitored figures). This can be 
> achieved using a 1:n PST or even out-of-band messaging so long as the 
> monitored LSP is identified.
Here I do not understand.
PM is about packet loss measurement, delay measurement, ... so a bit
more than what you seem to suggest.
Did I miss something?
> 
> Thus, we struggled to find the requirement for per-LSP monitoring, and 
> so we could not find any requirement to mandate not offering 1:n OAM PSTs.
> 
I do not recall such strong positions but what is important is that
consensus was reached :-)

> 
>>> When you reserve b/w for an LSP you must reserve enough b/w for all 
>>> the OAM that MIGHT be used on the LSP
>>
yes and no :-)
reserving extra bandwidth on the lsp is a (the?) solution such that OAM
messages do not start causing packet loss in that LSP.

> 
> We cannot specify that an LSR must treat the OAM packets differently 
> from the data packets (for example, making sure that the OAM is dropped 
> in preference to the data) because that contradicts the fate sharing 
> rules. And it might be hard for the LSR to tell which packets are data 
> and which are OAM.
> 
> So, in order to ensure that the OAM packets do not cause disruption to 
> the data, we must ensure that the packets are expected, and that there 
> are sufficient buffers to handle them.
> 
> Cheers,
> Adrian
> 
> 

regards,
martin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 18 Dec 2008 08:11:19 -0500

I¹d agree with Neil¹s points; we have no such requirements for
nesting/interworking.

    --Tom

On 12/18/08 5:24 AM, "[email-masked]" <[email-masked]>
wrote:

> Can I ask which operators want all this complex OAM, and esp the nested TCM
> stuff?  Act/deact of *simple* defect detection/handling trail term pt OAM (ie
> CV flow) in sync with signalling is defintely required, but we have no
> requirements at all for lots of of nested TCM levels.
>  
> Please keep in mind this very simple point:  If a network requires lots of OAM
> to be running to keep it operational then that network is already broken and
> not fit for purpose.  Real world networks MUST operate such that very little
> OAM is required for their normal day-day operation.  We generally only want
> the more complex diagnostics OAM (in which I include PM stuff) on a rare
> on-demand basis.
>  
> interworking OAM (or any other DP/CP/MP components) between different network
> modes/technologies which are not top-of-stack.
>  
> regards, Neil
> 
>>  
>>  
>> 
>> Of Greg  Mirsky
>>> (which would be a significant change) or to interleave  control with data
>>> and require ordered processing.
>>> 

-- 
Principal Architect - 21CN Networks

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 15:22:55 +0100

Rec. Y.1731 contains a specification of the mechanism to count frame loss
within a ME (refer to clause 8.1/Y.1731). 
The 'start counting' and 'end counting' type messages in Y.1731 are for
pro-active monitoring the CCM PDUs and for on-demand monitoring the LMM
PDUs. Counting however does not stop when a CCM [or LMM] frame is sent, or
is received... only the counter value at the time of sending/receiving is
latched. 
In the MEP Source function this latched counter value is then inserted in
the 'Transmitted Frame Count (TxFC)' field of the CCM or LMM frame. In the
MEP Sink function this latched counter value is stored as 'Received Frame
Count (RxFC)'  together with the value in the 'Transmitted Frame Count'
field of the received CCM or LMM frame. 
The number of lost frames between two successive CCM [or LMM] PDUs is then
computed in the MEP Sink function by computing the number of frames
transmitted by the MEP Source between two successive CCM [or LMM] PDUs, by
computing the number of frames received by the MEP Sink between two
successive CCM [or LMM] PDUs and then computing the difference between those
two values (transmitted frames minus received frames).
This 'number of lost frames between two successive CCM PDUs' is then used
for DEGraded defect (dDEG) determination and for Performance Monitoring
(number of near-end lost frames and then ES, SES and BBC). 
This 'number of lost frames between two successive LMM PDUs' is then used to
compute a frame loss ratio snapshot.
 
These 'start counting'/'end counting'  type OAM PDUs must  be sent
interleaved in the data to ensure in-order delivery with the data being
counted.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: woensdag 17 december 2008 16:37
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Hi Adrian, 

Regards,
Greg

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 18 Dec 2008 10:39:43 -0500

Considering the considerable debate in SG12 and MEF on Y.1731
definitions and their recent liaisons to SG15, we should ensure we are
aligned also with those groups and their preferred definitions.
Especially considering the network operator's input in those groups vs.
this equipment view.

Deborah

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Thursday, December 18, 2008 9:23 AM
To: 'Greg Mirsky'; 'Adrian Farrel'
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Rec. Y.1731 contains a specification of the mechanism to count frame
loss within a ME (refer to clause 8.1/Y.1731). 

The 'start counting' and 'end counting' type messages in Y.1731 are for
pro-active monitoring the CCM PDUs and for on-demand monitoring the LMM
PDUs. Counting however does not stop when a CCM [or LMM] frame is sent,
or is received... only the counter value at the time of
sending/receiving is latched. 

In the MEP Source function this latched counter value is then inserted
in the 'Transmitted Frame Count (TxFC)' field of the CCM or LMM frame.
In the MEP Sink function this latched counter value is stored as
'Received Frame Count (RxFC)'  together with the value in the
'Transmitted Frame Count' field of the received CCM or LMM frame. 

The number of lost frames between two successive CCM [or LMM] PDUs is
then computed in the MEP Sink function by computing the number of frames
transmitted by the MEP Source between two successive CCM [or LMM] PDUs,
by computing the number of frames received by the MEP Sink between two
successive CCM [or LMM] PDUs and then computing the difference between
those two values (transmitted frames minus received frames).

This 'number of lost frames between two successive CCM PDUs' is then
used for DEGraded defect (dDEG) determination and for Performance
Monitoring (number of near-end lost frames and then ES, SES and BBC). 

This 'number of lost frames between two successive LMM PDUs' is then
used to compute a frame loss ratio snapshot.

Regards,

Maarten

Behalf Of Greg Mirsky

Hi Adrian, 
I'd ask about OAM control and control messages. You've mentioned that
control of OAM functions, at least for packet counting, must be sent
over the data path.

	Performance measurement capabilities are required per LSP in any
ME on the ME
	It is important to clarify what is meant by performance
measurement!
	- Packet counts
	 Mechanisms that count the number of OAM packets lost
	 are probably not very helpful as they don't tell us anything
	 about the data loss/delivery. In fact, the use of OAM in
	 that way might very well change the performance of the
	 LSP.
	 Thus, we need "start counting" and "end counting" messages.
	  - These must be sent interleaved in the data to ensure
	     in-order delivery with the data that is being counted.

I think that control of OAM is not necessarily done over the the Data
Plane.

Regards,
Greg

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 08:06:11 -0800

Rube Goldberg comes to mind.
(http://en.wikipedia.org/wiki/Rube_Goldberg) 

>Sent: Thursday, December 18, 2008 6:23 AM
>Rec. Y.1731 contains a specification of the mechanism to count 
>frame loss within a ME (refer to clause 8.1/Y.1731). 
>The 'start counting' and 'end counting' type messages in 
>Y.1731 are for pro-active monitoring the CCM PDUs and for 
>on-demand monitoring the LMM PDUs. Counting however does not 
>stop when a CCM [or LMM] frame is sent, or is received... only 
>the counter value at the time of sending/receiving is latched. 
>In the MEP Source function this latched counter value is then 
>inserted in the 'Transmitted Frame Count (TxFC)' field of the 
>CCM or LMM frame. In the MEP Sink function this latched 
>counter value is stored as 'Received Frame Count (RxFC)'  
>together with the value in the 'Transmitted Frame Count' field 
>of the received CCM or LMM frame. 
>The number of lost frames between two successive CCM [or LMM] 
>PDUs is then computed in the MEP Sink function by computing 
>the number of frames transmitted by the MEP Source between two 
>successive CCM [or LMM] PDUs, by computing the number of 
>frames received by the MEP Sink between two successive CCM [or 
>LMM] PDUs and then computing the difference between those two 
>values (transmitted frames minus received frames).
>This 'number of lost frames between two successive CCM PDUs' 
>is then used for DEGraded defect (dDEG) determination and for 
>Performance Monitoring (number of near-end lost frames and 
>then ES, SES and BBC). 
>This 'number of lost frames between two successive LMM PDUs' 
>is then used to compute a frame loss ratio snapshot.
> 
>These 'start counting'/'end counting'  type OAM PDUs must  be 
>sent interleaved in the data to ensure in-order delivery with 
>the data being counted.
> 
>Regards,
>Maarten
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Greg Mirsky
>I'd ask about OAM control and control messages. You've 
>mentioned that control of OAM functions, at least for packet 
>counting, must be sent over the data path.
>
>
>
>
>	Performance measurement capabilities are required per 
>LSP in any ME on the ME
>Unless we require that action upon such OAM control is 
>instantaneous and takes effect on the next immediate packet I 
>don't think that OAM control must follow data path. If precise 
>counting is required it perhaps can be achieved actually 
>scheduling certain actions.

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 18 Dec 2008 21:30:50 +0100

Dear Deborah,

> aligned also with those groups and their preferred definitions. 

Would you please be so kind to elaborate on the above.

What was the topic of the debate?
And if possible can you tell me the where I can find the liaisons
you mention?

As the rapporteur of Q10/15 I have the responsibility of Y.1731,
which was discussed in the recent SG15 meeting. However there
were no incoming liaisons from SG12 nor MEF.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp