The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Questions:
1. There is no explicit description of operation of OAM in the
    presence of PHP. Should there be?
2. Call me a pedant if you like, but where section 3.4 describes
    measuring the SLA shouldn't it really talk about measuing the
    service and comparing it with the SLA?
3. There is no requirement placed on the avoidance of the negative
    impact of OAM on the customer's service.
4. Section 3.7 describes error detection and recovery. While it is
    clearly the responsibility of OAM to assist in error detection
    and reporting, I don't see OAM playing any further part in
    recovery. Should you re-cast this section in terms of facilitation
    of recovery?
5. 3.10.1 has
      (2) At an intermediate LSR, accounting of traffic through
          LSPs for each pair of ingress to egress.
    This is interesting. If the label stack has just one label then I
    guess we can peep inside (if the payload is IP). Is this what
    you intended, or is this requirement really only limited to
    "non-merging" LSPs such as LSP tunnels?
6. I think the security section is a bit weak. traceroute and ping
    have long been considered to have important security considerations
    beyond simple exposure of private network topologies. I think this
    is an important area where you should get some advice from a
    security expert.

I know the RFC editor can sort out these types of problems, but given the amount of
pressure that the editor is under at the moment, we should really try to clean up our
drafts vefore pushing them through last call. Here are a few nits from a brief scan of the
draft.

The draft should indicate its category. Informational or standards track?

Indentation is varried between sections

Abstract
   Detection and specification of how to handle those defects is not
   only important because such defects may not only affect the
   fundamental operation of an MPLS network, but also because they
   may impact SLA commitments for customers of that network.
The use of "not only" twice is confusing.

Abstract
   This Internet draft describes requirements for user and data
Please state "This document"

Abstract
   This Internet draft describes requirements for user and data
   plane operations and management (OAM) for Multi-Protocol
   Label Switching (MPLS).
Insert final word "networks"

Abstract
   This draft specifies OAM
   requirements for MPLS, as well as for applications of MPLS such
Please state "This document"

Abstract contains citations by reference. It mustn't.

Page numbers in index are out of date

Introduction
   This Internet draft describes requirements for user and data
Please state "This document"

Introduction
   This Internet draft describes requirements for user and data
   plane operations and management (OAM) for Multi-Protocol
   Label Switching (MPLS).
Insert final word "networks"

Introduction
   This draft specifies OAM requirements
   for MPLS,
Please state "This document"

Introduction
   No specific mechanisms are proposed to address these
   requirements at this time.
Say rather "in this document" (time is relative :-)

Introduction
   The goal of this draft is to
   identify a commonly applicable set of requirements for MPLS
   OAM.
Please state "...this document"

Section 2 formating is off

Section 2 (and remainder of doc)
   LSP:   Label Switch Path
"Switched"!

Section 2 (and remainder of doc)
   LSR:   Label Switch Router
This is one of Loa's favorites. Best get it right!

Section 3
   For example, the use of RSVP or LDP
   signaling and defects may be covered in some deployments,
Please say "RSVP-TE"

Section 3
   As MPLS matures relationships
   between providers has become more complex.
Please read
   As MPLS matures, relationships
   between providers have become more complex.

Section 3
   Furthermore, the
   deployment of multiple concurrent applications of MPLS is common
   place.
"commonplace" is a single word

Section 3 Requirements
How many section 3s are you allowed? :-)

Section 3.1, 3.2, 3.3 headings needs to be out-dented

Section 3.1
   instead,this function
   should be automated and performed from the origination of that LSP.
read "instead, this function"

Section 3.1 contains several stray double spaces. Suggest you search the whole document.

Section 3.1
   If the time to detect is known, then automated responses can be
   specified both w.r.t.with regard to resiliency and SLA
   reporting.
Erm... "w.r.t. with"?

Section 3.1
   For example, failures can
   be may occur where inconsistencies exist between the IP and MPLS
   forwarding tables, inconsistencies in the MPLS control and data
   plane or problems with the reply path (i.e.: a reverse MPLS
   path does not exist).
Something wrong with this sentence beyond "...failures may occur..."

Section 3.2 needs spaces between paragraphs

Section 3.2
   This is particularly true for
   misbranching defects which are particularly difficult to specify
   recovery actions in an LDP network.
???
   This is particularly true for
   misbranching defects for which it is particularly difficult to specify
   recovery actions in an LDP network.

Section 3.2
   Experience suggests that this is best accomplished via a path
   trace function that can return the entire list of LSRs and links
   used by a certain LSP (or at least the set of LSRs/links up to the
   location of the defect) is required.
Delete "is required"

Section 3.3
   The ability of a path trace function to reveal details of LSR
   forwarding operations relevant to OAM functionality.
This is not a sentence.

Section 3.5 You have two of these, too.

Section 3.5 (the first)
   The operator MUST be have the flexibility to configure OAM
Delete "be"

Section 3.5 (the second) capitalisation in header

Section 3.5 (2nd)
   Devices must provide alarm suppression functionality that
   prevents the generation of superfluous generation of alarms.
Delete "generation of"

Section 3.8 is missing a title

Section 3.8
    This
    will be reflected in the the integration of standard MPLS-related
    MIBs
Read "MIB modules"

Section 3.8
     (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB])
Punctuate

Section 3.8
    These standard interfaces
    provide operators with common programmatic interface access to
Are MIB modules interfaces?

Section 3.9 appears to be empty

3.10 formating

3.10
     In an MPLS network, SPs can measure traffic from an LSR to the
     egress
     of the MPLS network using some MPLS related MIBs, for example.
- say "MIB modules"
- give the specific MIB modules in your example?

3.10
     This means that it is reasonable wish to know how much traffic is
"a reasonable"

3.10
         For the purpose of optimized network design, SP offers that the
         traffic information regarding among POP and/or router.
Meaning?

3.10.1
      (4) All LSRs that contain LSPs that are being measuremented
"measured"

3.10.1
          The key must be unique to each LSP, and its mapping to
          LSP should be provided from whether manual or automatic
          configuration.
Meaning?

3.10.2 formating

3.10.2
     It is not realistic to perform the just described operations by
     LSRs in a network and on all LSPs which exist in a network.
     At a minimum, per-LSP based accounting should be performed on the
     edges of the network -- at the edges of both LSPs and the MPLS
     domain.
I'm not sure that this makes full sense.

References are very out of date

Copyright date is wrong.

IPR boilerplate needs to be updated to RFC3667 etc.

Missing final page throw


Cheers,
Adrian