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

From: "Malcolm Betts" <[email-masked]>
Date: Fri, 1 May 2009 14:24:34 -0400

Adrian,

Thank you for your comments.

One question for clarification on security:  Are you suggesting that we
should have a general section for security requirements e.g.
authentication of the sender; or that we should have security
requirements explicitly for each function; or ????

I notice that you agree that we should separate the notification of lock
from the remote alarm issue.  So I suggest that we break my initial
proposal into 4 parts and discuss them on different threads:

1) Lock and Notification of Lock
2) Differentiation between local and remote faults
3) Reaction to a CV defect
4) Client failure indication

Look for emails on each of these topics some time later today.

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

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 6:23 PM
To: Betts, Malcolm (CAR:X632); [email-masked]
Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of
MPLS-TP OAMrequirements

Thanks Malcolm,

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

> 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.

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

> 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.

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
>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>.

Yes. I support this segmentation.

> 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.

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
> 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.

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.

> 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.

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 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.

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.

> 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.

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).

> 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.

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."

> 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.

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

> 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.

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 tool.  My vote would be to always use this tool since it provides

> consistent client independent operation.

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 pro-actively.
>
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2009 22:00:20 +0100

Hi Malcolm,

> One question for clarification on security:  Are you suggesting
> that we should have a general section for security requirements
> e.g. authentication of the sender; or that we should have security

It works for me that you have just the existing security section. That 
should discuss requirements for security.

My original mail was basically saying "OK as far as it goes, but you need to 
add more stuff" and then made a note on one thing you need to add.

> I notice that you agree that we should separate the notification
> of lock from the remote alarm issue.

I do. But I am just one person.

> Look for emails on each of these topics some time later today.

Oh, I think I may go to bed :-)

Cheers,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 3 May 2009 12:19:20 +0200

Malcolm,

I hope you had the chance to look at (and resolve :-)) my comments. 

Please see more comments:

*         You need to define what a local fault is and what a remote
fault is. I can think about different interpretations for these. I can
see a requirement to detect a fault in a particular layer network. Is
this local? 

*         I think you still miss a requirement for Alarm Notification,
and I do not think you can eliminate it and hide it behind the
requirement for "a node that detects a continuity check defect to
distinguish local and remote faults." These are two requirements. IMO,
the requirement for alarm notification specified in the MPLS-TP OAM
requirement is well described and does not refer to an implementation.

*         Please refer to my comments I sent on Friday. I attached it to
the mail.

I think it is already hard to track the proposed changes and we need to
see a clear proposal now. 

Best regards,

Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Malcolm Betts
Sent: Friday, May 01, 2009 9:25 PM
To: Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of
MPLS-TPOAMrequirements

Adrian,

Malcolm Betts

Nortel Networks

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

MPLS-TP OAMrequirements

Thanks Malcolm,

user

(operator) commands?

Question:

L

only MAY

things.

Does it mean...

(i.e.

say...

s/of client/of a client/

condition/ s/to/of/

client fault condition.

spoofed.)

Many thanks,

Adrian 

_______________________________________________

Mpls-interop mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-interop

Subject: Alarm notifications v002-MB.doc
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "MEAD team" <[email-masked]>, "ext Malcolm Betts" <[email-masked]>
Date: Fri, 1 May 2009 16:43:35 +0200

Malcom,

Please see my comment inside the attached.

Best regards,

Nurit

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 12:19:36 +0200

Malcolm,

for the alarm notification, I suggest that we have exactly the same
text as for Lock Indication.

2.2.z.  Alarm Indication
The MPLS-TP OAM toolset MUST provide a function to enable End Points
of a (server) LSP or Section to notify, of its faulty or defect
status, the End Points of (client) PWs or LSPs affected by this status.

This function SHOULD be performed between the End Points of a PW, LSP
or Section.
comment:
remains here the subtle issue that the notification is not between the 
end-points of the same e.g., LSP but between end-points of different
LSPs.

regards,
-m

Malcolm Betts a écrit :
> 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
> 
> 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.
> 
>    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 
>    The MPLS-TP OAM toolset MUST allow for the distinction between a
>    fault condition and an administrative locking action.
>    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.
> 
>    and Sections and the End Points of the PWs and/or LSPs affected by
>    the administrative locking.
> 
> function. It MUST also indicate if the fault causing this is local (i.e. 
> 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.
> 
> 
>    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 
> ------------------------------------------------------------------------
>