The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Tom/Monique,

I agree with you on the assumption that the requirements are indeed
correct.  When we are dealing with either of the co modes there is a
particularly important requirement on the base defect detection/handling
OAM (this is quite different to any ad hoc OAM for diagnostics or
Network Performance measurements say)....that is the OAM MUST:
-	reside in the data-plane of the traffic it is
protecting/monitoring
-	be unidirectional.

The latter requirement is rather important for these reasons:

1	the consequent actions (such as traffic suppression, raising
local alarms, sending FDI to suppress higher layer network alarms, etc)
MUST be done at the trail sink.
2	allows both p2p and p2mp cases to be handled scalably in a
similar manner.

For p2p cases there is a further requirement:

3	Virtually all applications using p2p trails have a
bi-directional availability requirement, ie if either direction fails
then it is usual for the application to fail.  This means unavailability
needs to be considered as an OR function of each direction.  The
implication of this is that any Network Performance measurements that
are in force for SLA purposes MUST be suspended in both directions when
the unavailable state is entered (in EITHER direction).  However, in the
available state Network Performance is a unidirectional measurement.
Note also here:
-	that Net Perf measurements must also be coupled to the trail
sink and are clearly unidirectional themselves
-	that there is a required 'ordering' of processes, viz:
	* mode defines relevant defects and required OAM (they are
different in in each network mode);
	* defects must be defined in terms of entry/exit criteria and
consequent actions;
	* if we want to keep things simple (and I recommend we do),
entry/exit of the unavailable state should be based only on defect
persistency, ie don't include network performance metrics in this if
possible;
	* once we have clearly defined available and unavailable 'time'
we have a correct basis for the measurement of network performance
SLAs....noting that both (un)availability and network performance SLAs
are important, but unless the above ordering is taken into account the
process of network performance measurements can be made either very
complex or meaningless.

regards, Neil

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Monique Morrow
> Sent: 21 December 2004 12:55
> To: Thomas D. Nadeau; mpls@ietf.org
> Subject: Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt
> 
> 
> I support this recommendation Tom -- this would be most efficent.
> 
> /monique
> 
> 
> On 21/12/04 7:27 am, "Thomas D. Nadeau" <tnadeau@cisco.com> wrote:
> 
> > 
> > I have a comment on draft-ietf-mpls-p2mp-sig-requirement-00.txt.
> > The paragraph below seems to on the one hand, have no 
> requirements as 
> > is stated in the last paragraph, does give a requirement. I suggest 
> > that this document simply refer to 
> > draft-ietf-mpls-oam-requirements-05.txt, since the WG agreed to 
> > include all MPLS OAM-related requirements in this draft.
> > 
> > --Tom
> > 
> > 
> > 4.18 P2MP MPLS OAM
> > 
> >     Management of P2MP LSPs is as important as the management of P2P
> >     LSPs.
> > 
> >     The MPLS and GMPLS MIB modules MUST be enhanced to 
> provide P2MP TE
> >     LSP management.
> > 
> >     In order to facilitate correct management, P2MP TE LSPs 
> MUST have
> >     unique identifiers.
> > 
> >     OAM facilities will have special demands in P2MP environments
> >     especially within the context of tracing the paths and 
> connectivity
> >     of P2MP TE LSPs. The precise requirements and 
> mechanisms for OAM are
> >     out of the scope of this document. It is expected that 
> a separate
> >     document will cover these requirements.
> > 
> > _______________________________________________
> > mpls mailing list
> > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls