RE: draft-harrison-mpls-oam-req-00.txt

["steven wright" <steven.wright@snt.BellSouth.com>]

A couple of Points....
1) Reqt#10
I think there is a class of errors associated with us the use of LSP
hierarchies that may not be covered here ?
Consider that a provider may have several TE LSPs ( e.g. with different QoS)
across a core network  into which lower level LSPs are label stacked. Even
though they may get to the right destination, they may get there through the
"wrong"  label stacked path.
unless you think this is covered under one of the other topics, I's suggest
adding  something like ...
     "(e) Incorrect use of Label hierarchy"

2) A missing Requirement on the "scope" of OAM mechanisms?
 The other OAM requirements result in a need to insert some packets into the
LSP in order to measure continuity, performance etc.
We need to ensure that such packets are :
(i) restricted to the service provider's network i.e do. not pass beyond the
egress of the LSP into a customer network
( I'll let braver souls debate what that means with respect to penultimate
hop popping ! 8^} )
(ii) not spoofed by customer traffic in the LSP data plane.

I'm not sure how you would meet the security requirements stated ins section
5 without this.
I believe the mechanisms proposed in draft-harrison-mpls-oam-00.txt did
attempt to do this..


3) This is editorial ...
I'd be tempted to refer to "mechanisms" rather than "tools" in a
requirements document. "Tools" sound like products. "mechanisms" may have a
variety of implementations including   protocol extensions as well as
specific tools.

Motivations #7 and #10 seem to be saying the same thing to me (and one I'd
agree with!). I'd suggest either merging them or rephrasing to explain why
they are different...


regards
Steven Wright


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Friday, May 18, 2001 6:32 PM
> To: 'internet-drafts@ietf.org'
> Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org'
> Subject: draft-harrison-mpls-oam-req-00.txt
>
>
> Hi,
>
> Please post the attached draft.
>
> Summary:
>
> This draft provides motivation and requirements for user-plane OAM
> (Operation and Maintenance) functionality in MPLS networks.
>
> Motivation for this recommendation rose from Network operators' need
> or tools that ensure reliability and performance of MPLS LSPs
> (Label Switched Paths). User-plane OAM tools are required to verify
> that LSPs have been setup and are available to deliver customer data
> to target destinations according to QoS (Quality of Service)
> guarantees given in SLAs (Service Level Agreements).
>
> Requirements presented in this draft include but are not limited to:
>
>  . Tools to efficiently detect and localize defects in MPLS layer
>  . Mechanisms for fast defect notification
>  . Availability and performance criteria
>  . Trigger for corrective actions (e.g. protection switching) when
>      failures occur.
>
>
> Regards,
> -Shahram Davari
>
>  <<draft-harrison-mpls-oam-req-00.txt>>
>