Subject: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAM requirements

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 30 Apr 2009 15:56:33 -0400

All,

You have probably seen the discussion on AIS on the MPLS-TP list.  On
the last MEAD team call we reached section 2.2.7 of the MPLS-TP OAM
requirements draft.  Section 2.2.8 Alarm Notifications addresses this
issue.

Below (in plain text) and attached in word with change bars etc. is a
proposal to revise sections 2.2.7, 2.2.8 and 2.2.9.
 <<Alarm notifications v002-MB.doc>> 
I would like to get a version of this text that the MEAD team can
support on the MPLS-TP as soon as possible to end this discussion.

Loa, I look to you for guidance on how to manage the lists e.g. should
we announce on the MPLS-TP that the MEAD team is reviewing text and wait
for a new draft?

2.2.7.  Lock

   The MPLS-TP OAM toolset MAY provide a function enabling to
   administratively shut down a PW, LSP or Section; that is, to stop
   user traffic being sent over that PW, LSP or Section.

The lock function MAY be applied to a unidirectional or bidirectional
PW, LSP or Section.  If the lock function is applied to bidirectional a
PW, LSP or Section then it SHOULD be possible to cause it to be applied
to both directions.

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

2.2.8.  Alarm Notification
MB> We should break this into several independent requirements:
notification of Lock: Local/remote fault causing loss of CC: Wrong CV
received <not sure if we need this, its implicit in 2.2.3>.

2.2.8a Notification of Lock

   The MPLS-TP OAM toolset MUST provide a function to enable the
   End Point at the ingress to notify the End Points at the egress that
the lock function is active.  The egress end points MUST notify the
local client layer that the server layer PW, LSP or Section has been
locked. 
MB> How this is used is out of scope for this draft.

   The MPLS-TP OAM toolset MUST allow for the distinction between a
   fault condition and an administrative locking action.
MB> Not sure we need this if we separate the requirements.

   The server layer End Points generating the notification and the
   client layer End Points receiving the notification may or may not be
   the same nodes.  A mechanism MUST be provided to support both cases.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between the End Points of PWs, LSPs
   and Sections and the End Points of the PWs and/or LSPs affected by
   the administrative locking.

2.2.8b Differentiation between local and remote faults.

When an MPLS-TP or PW end point detects a continuity check defect it
MUST provide a local indication to any clients and the management
function. It MUST also indicate if the fault causing this is local (i.e.
within the node containing the end point) or remote.

2.2.8c Connectivity verification failure

When an MPLS-TP or PW end point detects a continuity verification defect
it MUST provide a local indication to any clients and the management
function. It MUST also provide the capability to shut down the PW, LSP
or Section; that is, stop user traffic being sent from that PW, LSP or
Section.

2.2.9.  Client Failure Indication

   The MPLS-TP OAM toolset MUST provide a function to enable the
   propagation of client fault condition detected at the ingress to a
PW, LSP or Section, across the MPLS-TP
   network.
MB> The requirement to support the tool should be client independent, we
can, on a case by case basis for each client decide if we will use this
tool.  My vote would be to always use this tool since it provides
consistent client independent operation.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

   The MPLS-TP OAM toolset MAY provide a function enabling to
   administratively shut down a PW, LSP or Section; that is, to stop
   user traffic being sent over that PW, LSP or Section.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 Apr 2009 23:22:47 +0100

Thanks Malcolm,

Can the passive voice be cleaned up a bit? :-)

>  user traffic being sent over that PW, LSP or Section.

Enabling whom to administratively shut down a PW...?

> PW, LSP or Section then it SHOULD be possible to cause it to be applied

s/to bidirectional a/to a bidirectional/

> This function SHOULD be performed on-demand.

I'm not quite sure what this means. Do you mean, only in reaction to user 
(operator) commands?
Or do you mean only in reaction to some event trigger (which would seem to 
be a redundant thing to say).

>  This function SHOULD be performed between End Points of PWs,
>  LSPs and Sections.

Question:
In the unidirecitonal case I am unclear on the use of this OAM function.
Does the egress instruct the ingress to quiesce? Maybe, but if so, surely a 
midpoint could also issue the instruction.
Or does the ingress tell the egress that it has quiesced? But surely this is 
an alarm correlation notification, not a lock command.

So, in fact, isn't the *OAM* Lock function only applicable to bidirectional 
PWs, LSPs, and sections?
Other aspects of the lock function belong in the NM draft.

> 2.2.8.  Alarm Notification
L
> received <not sure if we need this, its implicit in 2.2.3>.

Yes. I support this segmentation.

> the lock function is active.

Unclear why these are "MUST" since the support of the lock function is only 
MAY

Thus, I think you need, "If the lock function is supported..."

> The egress end points MUST notify the

Quite agree. It is not a protocol requirements issue what the receiver of a 
notification does with that information. And there is nothing we can design 
into the protocol to make it happen. In fact, it is an implementation issue 
(and maybe an architectural issue).
So I would delete this sentence.

> MB> Not sure we need this if we separate the requirements.

I'd keep it. Even if the requirements are separated, without this sentence 
you might easily use the same mechanism to achieve multiple things.

> the same nodes.
> A mechanism MUST be provided to support both cases.

I'm puzzled! It appears that this notification is an inter-layer 
notification not an intra-layer notification.
If the layer boundary is within a node this is not a protocol issue and 
cannot be a protocol requirement.
If the layer boundary is on a link (a concept I really hate and don't really 
believe is meaningful!) then this is no different from the OAM on any other 
link and doesn't need to be mentioned.

> the administrative locking.

Sentence is a bit confusing!

Does it mean...
   This function SHOULD be performed between the End Points of the PWs,
   LSPs, or Sections affected by the administrative locking.

But this seems to contradict the inter-layer implications above since 
neither an LSP nor a PW can have its ends in different layers (and I'm not 
sure a section can either).

> within the node containing the end point) or remote.

This isn't a protocol requirement, is it?
It is partly an NM requirement, and partly an architecture/implementation 
requirement.
Essentially, this is function that forms part of 2.2.2 where it should 
say...
"The mechanism provided MUST enable a node that detects a continuity check 
defect to distinguish local and remote faults."

> or Section; that is, stop user traffic being sent from that PW, LSP or

Exactly as noted for 2.2.8b, but applied to 2.2.3.

> PW, LSP or Section, across the MPLS-TP network.

s/of client/of a client/
s/client fault condition/information pertaining to a client fault condition/
s/to/of/

> MB> The requirement to support the tool should be client independent,
> we can, on a case by case basis for each client decide if we will use this

Can we say "transparent propagation"?
That is, the MPLS-TP network should neither examine nor modify the client 
fault condition.

> This function SHOULD be performed between End Points of PWs,
> LSPs and Sections.

BTW, in the security section...
   Further, OAM messages MAY be authenticated to prove their origin and
   to make sure that they are destined for the receiving node.

These are protocol requirements, so I think this needs to be "mechanisms 
MUST be provided to allow OAM messages to be authenticated..." (I was 
prompted to think about this by considering a "lock" command that was 
spoofed.)

Many thanks,
Adrian