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

["Natale, Robert C (Bob)" <bnatale@lucent.com>]

Hello Shahram and the rest of the authors of this ID,

First, I do applaud the initiative and the effort invested in
this work...I think it is a very important topic for the WG to
address.  However, I do wish to offer some feedback -- hopefully
you will see it as constructive -- for further consideration.

1.  I am curious as to why you address "OAM" only, rather than
    "OAM&P".  It seems to me that -- over and above being
    important in its own right -- provisioning capabilities may
    be extremely helpful to realizing some of the "motivations"
    and satisfying some of the requirements you cite.

2.  I am somewhat skeptical about the focus on the user-plane
    versus the control-plane, management-plane, and interface(s)
    between the latter two.  Ensuring that we design control-
    plan capabilities and functionality to proactively avoid
    (minimize) the kinds of (legitimate) worries expressed in
    your "Motivations" #3 and #4, for example, should be a
    high priority for us.

3.  I am very skeptical about the focus on "tools" versus
    "capabilities", "features", "protocols", "interfaces" and
    so forth...you use "mechanisms" at one point and that is
    ok with me.  "Tools" sound like things we let the marketplace
    develop and deploy in response to the specs we design...?

4.  For example, in your "Requirements" section, the concluding
    sentence of #2 says: "It is necessary that be detected and
    notified automatically without operator intervention for this
    purpose."  I agree completely.  However, I read that as a
    strong mandate for control-plane capabilities.

5.  Wrt "Requirements" #4, scalability should mean "cost-
    effectively in smaller-scale networks" as well as
    "stably [or whatever] in large-scale networks".

6.  "Requirements" #6 sounds very close to app-level design
    (as do some other parts of the document).  While I agree
    with most of the objectives stated in this respect, it is
    an area that the IETF traditionally leaves to others to
    resolve.

7.  "Requirements" #7 *seems* to be written from the wrong
    perspective.  That is, it is not that "LSRs that do not
    support such functions must silently discard..." but
    rather that any specified new protocol features must not
    disrupt traffic processing in LSRs that do not support
    the features.  The intended outcome is the same, I know...
    but the suggested perspective will help to ensure that
    no backwards-incompatible features are introduced --
    unless they are consciously intended.

8.  "Requirements" #8 (measurements) seems like another clear
    example of control-plane functionality to me...ditto for
    #13 (failure detection).

9.  I also found some of the general wording (e.g., the various
    uses of "layer network") to be confusing, but that might
    just reflect lack of familiarity on my part.

In sum, I think this is important work and that it needs to be
expanded (to cover "OAM&P") and honed more toward control-plane
features and the control-plane/management-plane interface(s).

Thanks,

BobN

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> 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>> 
>