[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: DISCUSS and COMMENT on MPLS-OAM requirements and Framework

FYI, for those who commented.
I think I included all. Let me know if I missed any.

Bert

-----Original Message-----
From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of
Wijnen, Bert (Bert)
Sent: Thursday, December 01, 2005 14:40
To: Alex Zinin (E-mail)
Cc: Mpls (E-mail); Iesg (E-mail)
Subject: DISCUSS and COMMENT on MPLS-OAM requirements and Framework


Bert Wijnen:
Discuss:
[2005-12-01] As the OPS AD responsible for Network Management" I want to see the
final revisions of these documents. My understanding is there are
already newre versions going around. 

The below are SERIOUS shortcomings. Not sure if they are really
blocking, but for now I list them as DISCUSS, so I have a good
chance that the authors will take a serious look at it.

--- draft-ietf-mpls-oam-requirements-06.txt

- Sect 2 Terminology:
  I see (page 3)
    Head-end Label Switch Router (LSR): The beginning of a label
          switched path.
  and I see (also page 3):
    Head-end Label Switching Router (LSR): The beginning of a label
          switched path. A head-end LSR is also referred to as
          an Ingress Label Switching Router.
  Not sure I see/understand the difference (if there is any). 
  To me, it looks more as inconsitencies within the single document.

  I see (page 3):
    Collecting traffic: Passive measurement of network traffic.
  It appears twice (page 3 and page 4), but that does not make
  it less weird to me. What is it?

  I see (page 3):
    Probe-based-detection: Active measurement using a tool such as
          LSP ping.
  but I see it again on page 4. Why ??

- I find the usage of MAY (capitalized) quite confusing and distracting.
  I know that Mark has suggested to not botehr at this stage. But 
  I do find it troubling. Specifically since sect.2 seems to attach the
  RFC2119 meaning to this capitilized MAY.
  It is so much more disturbing becuase many of the SHOULD and MUST
  cases do indeed make sense.

- 4.9 Standard Management Interfaces
  It is unclear if the "required common information modeling of
  management and control of OAM functionality"  is met by the listed
  MIB module (note "MIB modules" as ipposed to "MIBs"), or if the
  idea is that more work needs to be done. I also wonder if ITU agrees
  that MIB modules is the answer to this requirement.

- I'll note that the titles in the Normative References sections are
  incorrect (i.e. not in sync with the real titles of the RFCs). And
  those are the documents for which some authors of THIS document are
  listed as co-AUTHORSE of those referenced documents.

--- draft-ietf-mpls-oam-frmwk-03.txt

The MPLS OAM framework document confuses me.
Framework documents often do so. Probably because my understanding
of a framework document is that it gives a picture of how all
existing things fit together in a framework, and (even more important)
how coming things can/should fit into the framework.

This document to me seems more of an "overview" or "discussion" of
various FCAPS aspects w.r.t. MPLS.  I think the comments from one of
the MIB doctors basically expresses the same concern.

So I would prefer to see the title changed to reflect that.
Since a new revision is expected anyway, I am taking a DISCUSS,
but I won't keep blocking if the WG decides they want to stick to
the existing title.

Comment:
[2005-12-01] ---------- MIB Doctor comments
Since new revisions are expected on both documents, let me just copy
some MIB doctor review comments, so that the authors can take this
into consideration for the new revisions.

--- from Mike Heard:

NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document;  I don't think imperatives belong
here at all).  Some acronyms in the abstract also may need to be expanded
there (judgment call).  Also replace "this draft" by "this document".  In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary).  Eliminate one of the
duplicate definitions of "Head-end Label Switch Router".  More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned.  I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble).  Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.

Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks.  I didn't
see any.  I am not sure what purpose this document serves.  I do not understand
why it needs to be published.

---- from Dan Romascanu:
draft-ietf-mpls-oam-requirements-06.txt
4.9 Standard Management Interfaces

  The wide-spread deployment of MPLS requires common information 
  modeling of management and control of OAM functionality. This is 
  reflected in the the integration of standard MPLS-related MIBs 
  (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and 
  configuration management. These standard interfaces provide 
  operators with common programmatic interface access to
  operations and management functions and their status.


... Beyond the word repetition in the 3rd line ...

What is (are) the requirement(s)? This is in a requirements section. A
common information model? Which one, needs it be defined in the IETF,
some other place? SNMP support? Define another MIB module for MPLS OAM?
The listed MIB documents have no direct relation with MPLS OAM. 

I believe that this section needs clarification and re-wording


---- from Bert Wijnen:
I actually reviewed a pre-copy of revision 4 for the frmwrk doc:

- I do not see why there is thus MUST/SHOULD/etc in the Terminology
  section. Only MUST is used once in the Security Considerations,
  and even there, a lower case must makes much more sense
- typos:
  section 1:
    the required the applicability of data plane OAM functions. Included
  s/the// at least once?
  figure 1:
  s/dignose/diagnose/
  top of page 7:
    able to automatically remove the defective resources from and the
  s/and// ??
- Mmmm I wonder:
  sect 2:
    FCAPS        Fault management, Configuration management,
                Administration management, Provisioning
                management, and Security management
  I thought that the P stands for Performance and not Provisioning.
  Anyway, if "Provisioning" is intended, then you may want to be
  consistent throughout your dopcument.
  sect 7, end of 2nd para:
    and authorization for OAM technologies is something that MUST be
    considered when designing network mechanism which satisfy the
    requirements presented in this document.
  I though "this document" is a "Framework" and not a "Requirements"
  document??