The MPLS WG Archive

["Serbest, Yetik" <Yetik_Serbest@labs.sbc.com>]

I have some comments on this draft. I categorized them below (requirements, editorials, general).

 

Thanks,

yetik

 

Requirements:

------------------

 

   3.1 Detection of Broken Label Switch Paths

   [snip]

   If the time to detect defects is specified and tools designed 

   accordingly then a harmonized operational framework can be 

   established both within MPLS levels, and with MPLS applications. 

   If the time to detect is known, then automated responses can be

   specified both w.r.t.with regard to resiliency and SLA

   reporting. One consequence is that ambiguity in maintenance 

   procedures MUST be minimized as ambiguity in test results impacts 

   detection time.

 

This requirement is ambiguous to me. We need the OAM tools, but we have to utilize the tools in a correct way to make the best out of them.  Does this requirement say that every OAM tool MUST do what it is supposed to do?

 

   [snip]

   Detection tools should have minimal

   dependencies on network components that do not implement the LSP.

Do we mean P routers here or non-MPLS routers by network components?

 

  3.2 Diagnosis of a Broken Label Switch Path

   The ability to diagnose a broken LSP and to isolate the failed

   resource in the path is required.

 

What specific resource is intended here? A PE router's CPU can be overloaded, and its routes can flap, which may result in LSP flapping. Do we want MPLS OAM tools to determine that the CPU of that PE is the root-cause?

 

   3.3 Path characterization

   The ability of a path trace function to reveal details of LSR

   forwarding operations relevant to OAM functionality. This would 

   include but not be limited to:

     - use of pipe or uniform TTL models by an LSR

     - externally visible aspects of load spreading (such as

       ECMP), including type of algorithm used

       examples of how algorithm will spread traffic

     - data/control plane OAM capabilities of the LSR

     - stack operations performed by the LSR (pushes and pops)

The first sentence is not complete. Hence I do not understand this section. Does the bullet list provide the conditions when the path trace gives useful results?

 

   3.5 Frequency of OAM Execution

   [snip]

   To elaborate, there are defect conditions (specifically

   misbranching or misdirection of traffic) for probe based detection

   mechanisms combined with automated network response requires 

   harmonization of probe insertion rates and probe handling across 

   the network in order to avoid flapping.

This is not clear. I believe it says that the determination of the frequency of OAM Execution is not science, therefore flexibility is needed to be able to adjust based on the network observations. Is that true?

 

   One observation would be that commoditization of MPLS, common

   optimized implementation of monitoring tools and the need for inter-

   carrier harmonization of defect and SLA handling will drive

   specification of OAM parameters to commonly agreed on values and

   such values will have to be harmonized with the surrounding

   technologies (e.g. SONET/SDH, ATM etc.) in order to be useful.

 

What does commoditization (I don't know if there is such a word) mean here? Does it mean "wide-spread deployment"?

 

I find this section not clear, the sentences are too long.

 

   3.6 Support for OAM Interworking for Fault Notification

   An LSR supporting OAM functions for pseudo-wire functions that

   join one or more networking technologies over MPLS must be

   able to translate an MPLS defect into the native technology's

   error condition. For example, errors occurring over the MPLS

   transport LSP that supports an emulated ATM VC must translate

   errors into native ATM OAM AIS cells at the edges of the pseudo-

   wire. The mechanism SHOULD consider possible bounded detection 

   time parameters, e.g., a "hold off" function before reacting as 

   to harmonize with the client OAM. One goal would be alarm 

   suppression in the psuedo-wire's client layer. As observed in 

   section 3.5, this requires that the MPLS layer perform detection 

   in a bounded timeframe in order to initiate alarm suppression 

   prior to the psuedo-wire client layer independently detecting the 

   defect.

 

Does this not belong to PWE3?

    3.8 The commoditization of MPLS will require common information

    modeling of management and control of OAM functionality. This 

    will be reflected in the the integration of standard MPLS-related 

    MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics

    and configuration management. These standard interfaces

    provide operators with common programmatic interface access to

    operations and management functions and their status.

No title. What is the requirement?

    3.9 Detection of Denial of Service attacks as part of security

    management.

No section body text. Can you elaborate a little bit?

 

    3.10 Per-LSP Accounting Requirements

      [snip]

     (1) Collecting information to design network

         For the purpose of optimized network design, SP offers that the

         traffic information regarding among POP and/or router.

         Optimizing network design needs this information.

     (2) Providing high-level SLA

What does high-level SLA mean? Does it mean stringent?

 

     3.10.1 Requirements

     Accounting on a per-LSP basis encompasses the following set of

     functions:

      (1) At an ingress LSR accounting of traffic through LSPs

          beginning at each egress in question.

      (2) At an intermediate LSR, accounting of traffic through

          LSPs for each pair of ingress to egress.

 

I think by intermediate LSR you mean P routers. How can a P router provide accounting for every LSP from ingress to egress (PE-to-PE)?

 

Editorial:

---------

 

Incomplete sentences (e.g., missing verbs), too long and hard to follow sentences, grammatical errors ("MUST be have", "can may be").

I think it is better to use Service Level Specifications of SLAs rather than SLAs, as an SLA includes financial agreements as well.

PWE3 Framework is no more, instead you better use PWE3 Architecture as a reference.

 

General:

--------

 

I find the draft hard to follow.