Document:   draft-ietf-mpls-oam-requirements-06.txt
Reviewer: David Black
Review Date: Mon, 21 Nov 2005 12:24:27 -0500 
Telechat Date:  Thursday 12/01/2005

Summary: Ready with nits

Note: this draft was reveiwed along with draft-ietf-mpls-oam-frmwk-03.txt

Review:
-------
The requirements draft needs enough attention that a new version
would be a good idea, especially as there may be a technical issue
hidden in Section 4.1's discussion of why ICMP is insufficient for
MPLS OAM purposes.  The conclusion that ICMP is insufficient is
correct, but some of the examples that are used to support the
conclusion may be incorrect about control-vs-data-plane handling
of ICMP by MPLS LSRs.

I found a significant number of typos and English language
editorial cleanup nits that I'll leave to the RFC Editor to
address.  It might be good to alert the RFC Editor that this
draft is likely to require heavy editorial attention.

Section 2.1 Terminology - Both "Head-end Label Switch
Router (LSR)" and "Head-end Label Switching Router (LSR)"
are defined.  Only one of these two definitions should be
used - the other should be removed.

Section 2.2 Acronyms - 

   LSP:  Label Switch Path

   LSR:  Label Switch Router

I suspect those should be "Label Switched Path" and "Label
Switching Router".  In any case, between this and the previous
comment, consistency on whether "LS" in acronyms stands for
"Label Switch" vs. "Label Switched" and/or "Label Switching"
is needed throughout the draft.

Section 3 Motivations - RFC 2119 terminology is not appropriate
in this section, as it does not express requirements.  Change
all occurrences of "MAY" to "may".

The statement that:

   However as of this writing, existing drafts focus on single 
   provider solutions or focus on a single aspect of the MPLS 
   architecture or application of MPLS.

appears to be inconsistent with Section 4.9's discussion of
standard MPLS MIBs, which includes references to the RFCs that
specify them.  In addition, this statement will be dramatically
incorrect when the LSP Ping draft is published.  It should be
rewritten to be more about the drafts that respond to these
requirements rather than a criticism of what has gone before.

Section 4.1 Detection of Label Switched Path Defects

The characterization of "reasonable amount of time" for
detection as "both predictable and consistent" is incomplete.
For example, always detecting defects 47-48 hours after they
manifest in customer traffic is "both predictable and
consistent", but not "reasonable".  A ballpark/approximate
order-of-magnitude discussion should be added covering the
time frames in which LSP defects will likely affect customer
traffic, and the detection timeframes required for operator
detection to precede customers noticing that something is
wrong.

The discussion of ICMP-based ping appears to assume that
ICMP-based ping is an MPLS control plane function, even at
LSRs that only forward an ICMP packet (i.e., not the destination
of the ICMP packet, and not the node at which the TTL hits zero).
If that assumption is correct, it needs to be stated, but it
does not appear to be consistent with RFC 3032's discussion
of ICMP and MPLS, which specifically states that ICMP packets
can be label switched.  If ICMP-based ping goes through the
data plane as long as the TTL has not expired (which is what
I would expect), then this paragraph needs to be reworked.

Section 4.4 Service Level Agreement Measurement

    ... the qualitative 
   aspects of LSPs such as jitter, delay, latency and loss 

I believe "quantitative" should be substituted for "qualitative".

Section 4.5 Frequency of OAM Execution

   ... probe-based detection mechanisms 
   that incur significant mismatches in the probe rate 

That doesn't parse for me - what is mismatched to what?  If
it's the rates of probing by multiple probe-based mechanisms,
the text quoted above should read:

	... probe frequency or rate differences among multiple
	probe-based detection mechanisms

At the end of the section, I understand how synchronizing
probe rates helps address the problem of inconsistent views of
network problem state, but explanation is needed for how
"having the probes self-identify their probe rate" helps.

Section 4.11 Per-LSP Accounting Requirements - ASBR acronym
used without expansion or definition.

Section 4.11.1 Requirements - The use of the word "key" in
(4) invites confusion with security usage of that word.
Please pick another term such as "tag" or "identifier",
unless there is a specific need to use "key".

Section 4.11.2 Scalability - This is not about "scalability"
per se, but rather minimum accounting requirements motivated
by scaling considerations.  It should be retitled to "Location
of Accounting" or something like that.

Section 5 Security Considerations

The term "tools" in the first paragraph should be changed
to "network mechanisms", which is I believe this paragraph
is primarily about (e.g., authorization restrictions on use
of LSP Ping); tools is susceptible to being misread as being
primarily about the software applications that inspect the
network as opposed to the network mechanisms they use.

Sections 6 and 11 on IANA Considerations are duplicative
(but consistent).  Remove one of them.