Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-oam-req-05

[Ballot discuss]
- Section 4.1
  RBridges MUST have the ability to identify OAM frames destined for
  them or which require processing by the OAM plane from normal data
  frames.

OAM plane, is this a new term?
Too many planes these days: control, data, management, and now OAM?

[Ballot comment]
COMMENTS, but please let's discuss them, except the editorial ones at the end.

- Section 4.6.1 Packet Loss and Section 4.6.2 Packet Delay

I really hope that you don't intend to define a new protocol for this.
We have all what we need with OWAMP, TWAMP, or the IP SLA protocols.
Btw, I guess that you have active monitoring (synthetic traffic) in mind, right? This should be spelled out.

- Section 4.10

  OAM Defect Detection and Indication Framework  SHOULD provide
  methods to log defect indications to a locally defined archive such
  as log buffer or SNMP traps.

A SNMP trap is not a locally defined archive

- I'm always surprised to see a SHOULD or MAY in a requirements document.
A requirements document is composed of MUST, and the protocol tells if that feature is a MUST/SHOULD/MAY
For example:
  An RBridge SHOULD have the ability to verify the above connectivity
  tests on sections.
For example, the following sentence is not a requirement, that's a spec.
  Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX
  [RFC5101] for the purpose of performance monitoring.



EDITORIAL:
- I wonder why the following text is not part of the Terminology section?

  It is
  assumed that the readers are familiar with the OAM concepts and
  terminologies defined in other OAM standards such as [8021ag] and
  [RFC5860]. This document does not attempt to redefine the terms and
  concepts specified elsewhere.

- section 4.9
Not sure why you redefine the term Fault, already present in the terminology section.
  The term Fault refers to an inability to perform a required action,
  e.g., an unsuccessful attempt to deliver a packet [OAMOVER].

Same remark for Defect in section 4.10
  [OAMOVER] defines "The term Defect refers to an interruption in the
  normal operation, such as a consecutive period of time where no
  packets are delivered successfully."

[Ballot discuss]
For the avoidance of doubt I have no objection to the publication of this
document as an RFC subject to a number of small issues that should be
relatively easy to address.

======

4.2.1. Unicast

  An RBridge SHOULD have the ability to verify the above connectivity
  tests on sections. As an example, assume RB1 is connected to RB5 via
  RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to
  RB5 connectivity on the section from RB3 to RB5. The difference is
  that the ingress and egress TRILL nicknames in this case are RB1 and
  RB5 as opposed to RB3 and RB5, even though the message itself may
  originate at RB3.

This sounds like you are asking RB3 to impersonate RB1. This surely
needs some security requirements.

===

4.5. General Requirements


  OAM, as practical and as possible, SHOULD provide a single framework
  between TRILL and other similar standards.

The meaning of this should be clarified.

===

  The OAM Framework MUST be extensible to future needs of TRILL and
  the needs of other standard organizations.

That is surely an impossible requirement to fulfill.

===

5. Security Considerations

  Security Requirements are specified in section 4.8. For general
  TRILL security considerations please refer to [RFC6325]

I would have expected a somewhat deeper discussion on security
particularly given the impersonation that you are advocating.

[Ballot comment]


1. Introduction

  Success of any mission critical network depends on the ability to
.. arguably the success many non-critical networks depends on this also.

===

3. Terminology

Given the desire not to redefine terms, it is a pity that terms
such as Section, Flow, Connectivity, Connectivity Verification,
Fault and Failure cannot be defined as references to other RFCs.
The precise definition can be quite subtle.

I agree with Adrian about "partial segment"

===

4.6. Performance Monitoring

I am surprised that you have lots of requirements on simulated
traffic measurements and almost nothing on live traffic measurement.
It is as if live traffic measurement is rather an after-thought.
This is particularly the case since the actually measurements
needed are the same in both cases, and the instrumentation
techniques may be largely extent be identical depending on the
solution chosen.

===

4.8. Security and Operational considerations

  Methods SHOULD be provided to prevent OAM messages causing
  congestion in the networks. Periodically generated messages with
  high frequencies may lead to congestion, hence methods such as
  shaping or rate limiting SHOULD be utilized.

I am not sure why this is not a MUST?

===

4.11. Live Traffic monitoring

  OAM implementations MAY provide methods to utilize live traffic for
  troubleshooting and performance monitoring.

See earlier text, this seems a very sparse definition.

  Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX
  [RFC5101] for the purpose of performance monitoring.

I am not sure why you have solutions proposals here.

[Ballot comment]
I have no objection to the publication of this document as an RFC. I do
have a number of small comments you may wish to address along the way.

---

Section 3

  Section: The term Section refers to a partial segment of a path

Is there a difference between a segment of a path and a partial
segment of a path? From the example, it appears not. You might strike
"partial".

---

Section 4.2.1

  An RBridge SHOULD have the ability to verify the above connectivity
  tests on sections. As an example, assume RB1 is connected to RB5 via
  RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to
  RB5 connectivity on the section from RB3 to RB5. The difference is
  that the ingress and egress TRILL nicknames in this case are RB1 and
  RB5 as opposed to RB3 and RB5, even though the message itself may
  originate at RB3.

I find the placement of a requirement "SHOULD" in the example
disconcerting. It is also not clear from this text whether there is any
special casing of the requirement such that the section must terminate
at the end point of the path under test (e.g., would the section from
RB1 to RB4 have been equally acceptable in the example? what about RB2
to RB4?). Maybe a little text tweaking would clariy this.

---

Section 4.3

  OAM SHOULD provide the ability to perform a Continuity Check on
  sections of any selectable path within the network.

I suspect this should be "on any section of any selectable path"

---

Should 4.8 restate the importance of keeping OAM within the campus, and
perhaps add the importance of not allowing OAM into the campus
(especially "discovered OAM packets" that pop out of a tunnel)?

Should 4.8 also point out the concerns associated with path tracing and
exposure of network internals?

---

I think you have used RFC 6291 in a normative way.

===

I also found a bunch of nits...

---

You or the RFC Editor will want to fix the expansion of OAM to match
what they have in their list of standard abbreviations at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
This is consistent with RFC 6291.
The difference is the running comma.

---                                                                             

Abstract
"This document presents,"
Superfluous comma.

---

Section 1
  Success of any mission critical network depends on the ability to
  proactively monitor networks for faults, performance, etc. as well
  as its ability to efficiently and quickly troubleshoot defects and
  failures.
s/monitor networks/monitor it/
s/its/the/

---

Section 1
  In this document we define the Requirements for TRILL OAM.
s/Requirements/requirements/

---

You will need to sort out the separation between Authors and
Contributing Authors. Put the front page names in a separate section
called Authors Addresses.

[Ballot comment]
A note related to the shepherd writeup (a fine one; thanks, Don).

  Lastly, the nits checker doesn't like
  it that the Authors' Addresses section is called "Contributing
  Authors".

The RFC Editor won't like this either, but not just because of the title: they will want one section that contains the authors that are listed at the top of the document, and another that contains the others; such is their style.  That said, this is best left to the RFC Editor to sort out with you, and I suggest that the IESG shouldn't bother with it.

I found the Terminology section to be particularly clear and helpful.

Would a TRILL OAM system collect any TRILL-specific data that would need to be protected from a confidentiality point of view?  For example, might there be anything exposed about the topology, anything about flows, paths, or sections, which administrators would want to keep prying eyes away from?  Is there nothing related to that that ought to be included in the security considerations?

IANA has reviewed draft-ietf-trill-oam-req-04, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'Requirements for Operations, Administration and Maintenance (OAM) in
  TRILL (Transparent Interconnection of Lots of Links)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  OAM (Operations, Administration and Maintenance) is a general term
  used to identify functions and toolsets to troubleshoot and monitor
  networks. This document presents, OAM Requirements applicable to
  TRILL.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-oam-req/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-oam-req/ballot/


No IPR declarations have been submitted directly on this I-D.

Requirements for Operations, Administration and Maintenance (OAM) in
TRILL (Transparent Interconnection of Lots of Links)
draft-ietf-trill-oam-req-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Informational, as indicated on the title page. This is a
requirements documents, not a technical specification, but does
include RFC 2119 language to indicate the requirements for a
specification or specifications satisfying the requirements.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. The
approval announcement contains the following sections:

Technical Summary:

The TRILL protocol current supports SNMP and BFD but those provide
only limited OAM facilities. This document is the first in a planned
series of documents to provide more complete OAM facilities. It
gives requirements for those OAM facilities and is expected to be
followed by an OAM Framework document (currently a TRILL WG draft)
which is in turn expected to be followed by two detailed
specifications: Fault Management (current a personal draft) and
Performance Management (no draft posted at this time). While the
current direction of TRILL OAM is to parallel IEEE 802.1ag, this
requirement document is general independent of OAM technology and
does not constrain that direction.

Working Group Summary:

This document originated in the TRILL OAM design team. It was adopted
by a strong consensus and reviewed by the WG. Changes were made
based on review in the working group and there was a good consensus
to forward it for publication.

Document Quality:

There is significant vendor interest in more complete OAM facilities
for TRILL. This document has been thoroughly reviewed. It was
originated in the TRILL OAM design team and has also been reviewed
by a number of IEEE 802.1 voting members who volunteered to do so in
their individual capacity. In addition, it was closely reviewed
several times by Thomas Narten, a former Internet Area Director.

Personnel:

The Document Shepherd is Donald Eastlake.
The Responsible Area Director is Ralph Droms.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

I read through the draft carefully right after reading the
"Checklist for Internet-Drafts (IDs) submitted for RFC publication".
I have found only few editorial glitches that have now been fixed
and the nits listed in item 11 below.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

Operations Directorate review will be helpful and has been
explicitly requested, as this is an OAM requirements document.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed.

Yes.

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Not every TRILL WG participant is interested in or knowledgeable
about OAM but there was wide support for the document. There has
been explicit support by over a dozen WG participants and no one has
posted either opposing the document as a whole or opposing
advancement of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

There are three minor nits: [RFC4377] in not referenced in the body
and should be removed from the references section.
"draft-ietf-opsawg-oam-overview-06" in the references section is an
old version -- probably the version number should just be removed
from the partial file name. Lastly, the nits checker doesn't like
it that the Authors' Addresses section is called "Contributing
Authors". Also some of the entries in the Contributing Authors
section are not separated by blank lines.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No such formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state?

No.

(15) Are there downward normative references (see RFC 3967)?

No. This is an informational document.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document.

This is a requirements document and requires no IANA actions.

(18) List any new IANA registries that require Expert Review for
future allocations.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None required.