Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 May 2009 12:19:16 +0200

Malcolm,

With reference to my previous meail this morning in which I have described
the objective of Fault Management, I want to confirm that the requirement
you state below is not correctly reflecting the objective of fault
management and specifically the detection of loss of CC messages.

The requirement should be:

When a MPLS-TP equipment (or node) detects a loss of CC messages it MUST be
able to determine if that loss is either a primary fault caused by a fault
of one of the MPLS-TP connection functions within the MPLS-TP layer
connection, or a secondary/consequential defect due to a fault in a server
layer or sublayer that caused the interruption of a MPLS-TP link connection
supported by the server (sub)layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Malcolm Betts
Sent: donderdag 30 april 2009 14:34
To: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

ad hoc MPLS-TP co chair hat on:

All, the agreement between the IETF and the ITU is that the IETF will
develop MPLS-TP to fully meet the requirements of the transport network.
Clearly the requirements for MPLS-TP cannot and will not retroactively
change the requirements and functionality already deployed in transport
network.

A few days (and probably a few hundred messages) ago I thought we had
reached convergence on this issue.  We need to separate the requirement from
the implementation.  AIS is an implementation with an implicit requirement.

>From the perspective of the requirements:

When a MPLS-TP equipment (or node) detects a loss of CC messages it MUST be
able to determine if that loss is caused by a fault that's a) in the local
node or locally terminated link: or b) a fault in a remote node or remotely
terminated link.  The mechanism used to provide this local/remote fault
distinction SHOULD be highly reliable.

This is the function performed by AIS in PDH/SDH networks.

When we start working on the solutions draft we can decide how this
requirement can be met, we may also consider if the complexity of the
implementation is such that meeting this requirement is not a good
"engineering decision" - e.g. the implementation would not yield a highly
reliable result.

I will draft provide some draft text for the OAM requirements draft to
reflect this.  So for the moment can we please focus the discussion on the
requirement. I hope that this will allow us to close this point with respect
to the requirement.

Malcolm Betts
ad hoc MPLS-TP co chair
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lam, Hing-Kam (Kam)
Sent: Thursday, April 30, 2009 12:59 AM
To: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

All I can say is that the impact of this proposed change is very serious. 
Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead of
changing the ITU-T transport requirements?

Regards,
Kam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Maarten Vissers
> Sent: Thursday, April 30, 2009 12:27 AM
> To: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated
> bidirectionaltransportpathrequirements)
> 
> We are discussing a change of a general fault management principle.
This
> change will impact the following recommendations: G.806 (generic),
G.7710
> (generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN),
> G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and
> G.8121/G.8112/G.8151
> (MPLS-TP). This proposed change has implications beyond the scope of
MPLS-
> TP
> and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: woensdag 29 april 2009 19:57
> To: ext Thomas Nadeau
> Cc: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated
> bidirectionaltransportpathrequirements)
> 
> I agree!
> 
> -----Original Message-----
> From: ext Thomas Nadeau [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2009 1:01 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
> transportpathrequirements)
> 
> 
> 	It would be best is these "Tier-1 SPs" would comment directly on
the 
> list or contribute to the requirements draft.
> 
> 	--Tom
> 
> 
> On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon)
> wrote:
> 
> > Neil,
> > Thanks for the very good explanation. It really helps me to
understand
> > better the context of the long discussion.
> > Personally I got many feedbacks from Tier-1 SPs that they would like

> > to have the capability to suppress alarms in a packet transport 
> > environment. Their requirement was that if a server layer (e.g.
MPLS-
> > TP
> > link) fails, there is a way to notify the client layer (e.g. LSPs)
in
> > order to be able to suppress alarms at the client layer that may 
> > result from the fault at the server layer (e.g. MPLS-TP link).
> > Isn't it a logical and reasonable requirement in a transport
profile?
> > Also I saw general requirements for inter-layer fault correlation.
So
> > can I understand from your mail that you are not happy from such a 
> > requirement as well?
> > Best regards,
> > Nurit
> >
> >
> >
> > -----Original Message-----
> > From: ext [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 11:07 AM
> > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> > [email-masked]; [email-masked];
[email-masked]
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional
> > transportpathrequirements)
> >
> > Nurit,
> >
> > I believe the reason we need this discussion is that there is an 
> > unstated assumption here that the client/server relationship is
fixed.
> > However, if the client can dynamically change its routing in 
> > response to link failures in its topology (because some server layer

> > network has failed....which may or may not belong to the same 
> > operating party as the
> > client) then there is no fixed client/server relationship.
> >
> > Refer to my post earlier today and consider what this means in the 
> > case of a cl-ps IP client layer network or a some SVC-based 
> > co-ps/co-cs mode client layer network.  The key point here is the 
> > *routing process*
in
> > the client is independent of the server layer network....so there is

> > not a fixed client/server relationship.  Further, there is also no 
> > requirement for the server to keep track of where its client traffic

> > routings are at any epoch.....indeed why should it in the general
case
> > where these are independent layer networks?
> >
> > So the only OAM requirement that is critical is that the OAM of the 
> > client and server layer networks are independent.  It is thus not 
> > sensible to make client layer alarm supression a 'requirement'
> > here...in
> > fact if this is in the OAM requirements then it is technically wrong

> > and should be removed IMO.
> >
> > regards, Neil
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN

> >> - IL/Hod HaSharon)
> >> Sent: 28 April 2009 08:46
> >> To: ext BUSI ITALO; [email-masked]; Adrian Farrel
> >> Cc: [email-masked]
> >> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
> >> transportpathrequirements)
> >>
> >> If we agree that the requirement is included, so why do we keep 
> >> with the endless discussions on this requirement?
> >>
> >> -----Original Message-----
> >> From: ext BUSI ITALO [mailto:[email-masked]]
> >> Sent: Tuesday, April 28, 2009 10:44 AM
> >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
> >> Adrian Farrel
> >> Cc: [email-masked]
> >> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional 
> >> transport
> >> pathrequirements)
> >>
> >> I think that the requirements are defined in section 2.2.8 of
> >> draft-ietf-mpls-tp-oam-requirements-01
> >>
> >> Italo
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit 
> >>> (NSN - IL/Hod HaSharon)
> >>> Sent: Tuesday, April 28, 2009 6:56 AM
> >>> To: [email-masked]; Adrian Farrel
> >>> Cc: [email-masked]
> >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
> >>> transport pathrequirements)
> >>>
> >>> Huub,
> >>> I think that the requirement is to provide a mechanism to suppress

> >>> alarms in the networks, to ensure that alarms that may be
> >> generated by
> >>> client layers as a result of a failure condition in the server 
> >>> layer may be suppressed.
> >>> Every thing else is a solution, etc.
> >>> I propose to phrase the requirement appropriately and conclude the

> >>> discussion on this in the context of the requirements (until we
are
> >>> getting to the solution phase).
> >>> This requirement is included in the OAM requirement draft.
> >>> Best regards,
> >>> NUrit
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]
On
> >>> Behalf Of ext Huub van Helvoort
> >>> Sent: Tuesday, April 28, 2009 12:27 AM
> >>> To: Adrian Farrel
> >>> Cc: [email-masked]
> >>> Subject: Re: [mpls-tp] AIS/FDI (was Associated
> >> bidirectional transport
> >>> path requirements)
> >>>
> >>> Hi Adrian,
> >>>
> >>> You wrote:
> >>>
> >>>> Isn't the solution here the same as the one I proposed for "TCM"?
> >>>
> >>> Indeed, and that we do not have to around in circles about TCM.
> >>>
> >>> How about:
> >>> the requirement is that a server layer shall inform its clients 
> >>> that it has detected a service interuption, this to ensure that 
> >>> the clients can inhibit (unnecessary) alarms.
> >>>
> >>> Cheers, Huub.
> >>>
> >>> --
> >>> ================================================================
> >>>                   http://www.van-helvoort.eu/ 
> >>> ================================================================
> >>> Always remember that you are unique...just like everyone else...
> >>> _______________________________________________
> >>> mpls-tp mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>> _______________________________________________
> >>> mpls-tp mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp