Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16

[Ballot comment]

The security considerations points at RFC 3473 which in turn
says IPsec or RFC 2747 (from 2000) which has a HMAC-MD5
based integrity mechanism (still ok as far we we know) but
which also says that "It is likely that the IETF will define
a standard key management protocol." Ah well;-)

If there was something else that came along in the last 15
years that's better I guess it'd be good to note. But this
is non-blocking as this isn't the place to fix any such
issues except to the extent of adding some better
references.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 and has a note about the sixth action requested by the IANA Considerations section. Please check our conclusions and let us know if we misunderstood any of the actions.

IANA understands that, upon approval of this document, there are six actions which need to be completed.

First, in the OAM Types registry, under the RSVP-TE OAM Configuration Registry heading at

https://www.iana.org/assignments/rsvp-te-oam

a new OAM type will be registered as follows:

Type: [ TBD-at-registration ]
Description: MPLS OAM
Reference: [ RFC-to-be ]

Second, in the Ethernet Sub-TLVs Sub-Registry, under the RSVP-TE OAM Configuration Registry heading at

https://www.iana.org/assignments/rsvp-te-oam

a new sub-TLV will be registered as follows:

Type: [ TBD-at-registration ]
Description: PLS OAM Configuration sub-TLV
Reference: [ RFC-to-be ]

Third, IANA will create a registry called "MPLS OAM Sub-TLV Types" in the RSVP-TE OAM Configuration Registry located at:

https://www.iana.org/assignments/rsvp-te-oam/

The registry will be maintained via IETF Review as defined by RFC 5226 (except for values 65533-65534, which are reserved for Experimental Use).

Initial values in the new registry:

+-------------+--------------------------------+---------------+
|    Type    |          Description          | Reference    |
+-------------+--------------------------------+---------------+
|      0      |            Reserved            | [ RFC-to-be ] |
|      1      |  BFD Configuration sub-TLV    | [ RFC-to-be ] |
|      2      | Performance Monitoring sub-TLV | [ RFC-to-be ] |
|      3      |      MPLS OAM FMS sub-TLV      | [ RFC-to-be ] |
|  4-65532  |          Unassigned          |              |
| 65533-65534 | Reserved for Experimental Use  | [ RFC-to-be ] |
|    65535    |            Reserved            | [ RFC-to-be ] |
+-------------+--------------------------------+---------------+

Fourth, IANA will create a registry called "BFD Configuration Sub-TLV Types" in the RSVP-TE OAM Configuration Registry at

https://www.iana.org/assignments/rsvp-te-oam

The registry will be maintained via IETF Review as defined by RFC 5226 (except for values 65533-65534, which are reserved for Experimental Use).

Initial values in the new registry:

+-------------+-------------------------------------+---------------+
|    Type    |            Description            | Reference    |
+-------------+-------------------------------------+---------------+
|      0      |              Reserved              | [ RFC-to-be ] |
|      1      |      BFD Identifiers sub-TLV      | [ RFC-to-be ] |
|      2      |  Negotiation Timer Parameters sub-  | [ RFC-to-be ] |
|            |                TLV                |              |
|      3      |      BFD Authentication sub-TLV    | [ RFC-to-be ] |
|  4-65532  |              Unassigned            |              |
| 65533-65534 |    Reserved for Experimental Use    | [ RFC-to-be ] |
|    65535    |              Reserved              | [ RFC-to-be ] |
+-------------+-------------------------------------+---------------+

Fifth, IANA will create a registry called "Performance Monitoring Sub-TLV Types" in the RSVP-TE OAM Configuration Registry at

https://www.iana.org/assignments/rsvp-te-oam

The registry will be maintained via IETF Review as defined by RFC 5226 (except for values 65533-65534, which are reserved for Experimental Use.)

Initial values:

+-------------+-------------------------------+---------------+
|    Type    |          Description          | Reference    |
+-------------+-------------------------------+---------------+
|      0      |            Reserved          | [ RFC-to-be ] |
|      1      |    MPLS OAM PM Loss sub-TLV  | [ RFC-to-be ] |
|      2      |  MPLS OAM PM Delay sub-TLV  | [ RFC-to-be ] |
|  3-65532  |          Unassigned          |              |
| 65533-65534 | Reserved for Experimental Use | [ RFC-to-be ] |
|    65535    |            Reserved          | [ RFC-to-be ] |
+-------------+-------------------------------+---------------+

Sixth, the authors request registrations in the "Sub-codes - 40 OAM Problem" sub-registry.

NOTE: This sub-registry was a little hard to find. Would it be possible to add, in section 5.6, that the "Sub-codes - 40 OAM Problem" sub-registry is located in the "Error Codes and Globally-Defined Error Value Sub-Codes" registry?

The values to be added are:

+-----------------+---------------------------------+---------------+
| Error Value    | Description                    | Reference    |
| Sub-codes      |                                |              |
+-----------------+---------------------------------+---------------+
| TBA3            | Unsupported BFD Version        | [ RFC-to-be ] |
| TBA4            | Unsupported BFD Encapsulation  | [ RFC-to-be ] |
|                | format                          |              |
| TBA5            | Unsupported BFD Authentication  | [ RFC-to-be ] |
|                | Type                            |              |
| TBA6            | Mismatch of BFD Authentication  | [ RFC-to-be ] |
|                | Key ID                          |              |
| TBA7            | Unsupported Timestamp Format    | [ RFC-to-be ] |
| TBA8            | Unsupported Delay Mode          | [ RFC-to-be ] |
| TBA9            | Unsupported Loss Mode          | [ RFC-to-be ] |
| TBA10          | Delay variation unsupported    | [ RFC-to-be ] |
| TBA11          | Dyadic mode unsupported        | [ RFC-to-be ] |
| TBA12          | Loopback mode unsupported      | [ RFC-to-be ] |
| TBA13          | Combined mode unsupported      | [ RFC-to-be ] |
| TBA14          | Fault management signaling      | [ RFC-to-be ] |
|                | unsupported                    |              |
| TBA15          | Unable to create fault          | [ RFC-to-be ] |
|                | management association          |              |
+-----------------+---------------------------------+---------------+

IANA understands that these six actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Configuration of Pro-Active Operations, Administration, and
  Maintenance (OAM) Functions for MPLS-based Transport Networks using
  RSVP-TE'
  as Proposed Standard

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 2015-01-08. An extra week has been added
to this last call period to cover the vacations at this time of year.
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

  This specification describes the configuration of pro-active MPLS-TP
  (MPLS-Transport Profile) Operations, Administration, and Maintenance
  (OAM) Functions for a given LSP using a set of TLVs that are carried
  by the GMPLS RSVP-TE protocol based on the OAM Configuration
  Framework for GMPLS RSVP-TE.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1558/

Hi Greg,

Thanks for this.
Very nearly perfect.

Four things that are rather small and editorial:

If you run idnits you'll see that it gives warning about:

1. The absence of page throws.
2. The large number of references that are unused and that
  you can safely remove from the references section.
3. The reference to RFC 6060 that is made from the text and
  needs to be added to the references section.

Additionally:

4. By becoming an editor (which is a Good Thing) you have increased
  the front page author count above the magic number of five.
  The solution is either that you reduce the count (by removing someone
  from the front page and moving them from the "Authors' Addresses"
  section to the "Contributing Authors" section) or you get the
  document shepherd to update the write-up to explain why we need
  all six names on the front page.

Thanks for continuing to work on this.

Adrian

AD review
====
Hi,

Thanks to the authors for being patient with this draft. The CCAMP OAM
configuration framework draft and the Ethernet counterpart to this work
have now progressed far enough through the system that it is appropriate
to move this one forward, so I have done my usual AD review. The purpose
of the review is to catch some of the larger issues that might come up
in IETF last call and IESG evaluation. Catching them early helps save
everyone time, and improves the quality of subsequent reviews.

I have a few small editorial issues listed below and a request for
some careful reworking of the IANA section. This is open for
discussion if you have any concerns, but until then I have placed
the document in "Revised I-D Needed" state. When I see a new
revision I will advance the document to IETF last call.

Thanks for the work.

Adrian

====

Loa may want to change his affiliation.

---

Could you please remove the citation from the Abstract. Probably replace
it with "...the OAM Configuration Framework for GMPLS RSVP-TE."

---                                               

I think you can/should remove the ITU-T cooperation paragraph from the
Abstract and Introduction unless this work has been explicitly worked on
in a shared way by the two bodies.

---

You need to look through the document for unexpanded acronyms. I see
LER
LSR
NMS
LSP
MEP
FMS
G-ACh
PM

---

Section 1 has...

  Pro-active MPLS-TP OAM is performed by four different protocols

but I think you only list 3 (BFD, DM, and LM)

---

The penultimate paragraph of Section 1 comes along a little late, IMHO.

  MPLS-TP describes a profile of MPLS that enables ...

I suggest moving this to be the second paragraph.

---

I suggest moving Section 1.1 to be placed between sections 5 and 6 to
be more consistent with the RFC editor guidelines.

---

3.1.3

  When configuring Fault Management
  Signals, two options are possible, default configuration is enabled
  by setting the respective flags in the "OAM Function Flags sub-TLV",
  the default settings MAY be customized by including the "MPLS OAM FMS
  sub-TLV".

It took me a long time to parse the two options in this paragraph: once
I saw it, it was obvious.  I also think "the respective flags" is not
enough information. I suggest something like...

  When configuring Fault Management
  Signals, an implementation can enable the default configuration by
  setting the FMS flag in the "OAM Function Flags sub-TLV".  If an
  implementation wishes to modify the default configuration it includes
  a "MPLS OAM FMS sub-TLV".

---

You can safely remove some of the IANA allocation discussion from
Section 3.2 and leave it to the Section 5 where it is also stated.

---

Section 3.2

  Length: indicates the total length including sub-TLVs.

You need to be clear whether "total length" includes the T and L.
This applies to the definitions of the sub-TLVs as well.

---

Section 3.2

  The following MPLS OAM specific sub-TLVs MAY be included in the the
  "MPLS OAM Configuration sub-TLV":

You omit to say (but you imply) that it is legal to have zero sub-TLVs
present. Please clarify.

Also s/the the/the/

---

Section 3.2

What happens if a sub-TLV is included and the appropriate lag was not
set?

What happens if multiple copies of a sub-TLV are present?

What ordering of sub-TLVs is required?

What happens if a mandatory sub-TLV (according to flag settings etc.) is
not present?

---

Section 3.2

  Moreover, if the CV Flag is set, the CC flag SHOULD be set as well.

It would make sense for this and the following paragraphs to be in their
own subsection.

Please use the flag names as stated in [OAM-CONF-FWK]

I think that this "SHOULD" applies specifically to MPLS-TP usage. Can
you make that clear. Can you also explain in the text why this is not a
"MUST".

---

There is an alignment error in the figure in 3.3.1

---

Section 3.3.1
Shouldn't there be a reference to a BFD spec for Local Discriminator?

---

Section 3.3.2

  Acceptable Min. Asynchronous RX interval: If the S (symmetric) flag
  is set in the "BFD Configuration sub-TLV", this field MUST be equal
  to "Acceptable Min. Asynchronous TX interval" and has no additional
  meaning with respect to the one described for "Acceptable Min.
  Asynchronous TX interval".

If it MUST be equal, you have to handle it being different with an
error case. But since the field has no meaning in this case, why not
say it MUST be set equal and MUST be ignored on receipt?

---

Section 3.4

  In case the values need to be different than the default ones the
  "Performance Monitoring sub-TLV" MAY include the following sub-TLVs:

s/MAY include/includes/

---

Section 3.4.2

  Type: 2,"MPLS OAM PM Loss sub-TLV".

A victim of block copying, I think.

---

The IANA considerations and use of codepoints in the document need some
work.

Section 5 is reasonably clear, but it would help if you could break it
into subsections, one for each action.
- MPLS OAM Configuration Sub-TLV
- MPLS OAM Type
- New RSVP-TE OAM Configuration registry
- New BFD Configuration Type registry
- New Performance Monitoring Type registry
- New RSVP-TE error codes

It is really important to name the registries you are asking IANA to
allocate from. At least one of the registries does not exist yet, so
you need to state "[OAM-CONF-FWK] requests the creation of..."

For allocations from existing registries, do you *really* need the
values you have specified, or were you trying to be helpful?  Please
replace in this section and in the text...
- MPLS OAM  TBA1  (was 2)
- MPLS OAM Configuration Sub-TLV  TBA2  (was 33)
  - You should request allocation from the Technology-specific range

For existing registries, please build the table fragment here to
include all of the table columns defined in the registry.  There will
be at least a "Reference" column.

For each of the new sub-registries, please:
- note that they are sub-registries
- note that the parent registry is created by [OAM-CONF-FWK]
- add a column for "Reference" and populate it with [This.I-D]
- replace "Reserved" with "Unassigned" for the higher values
- state explicitly what the top of the range is
- state what the allocation policy is for new values with a reference
  to RFC 5226

For the error codes and error value sub-codes, it would be more helpful
if you could:
- indicate that the "values" to be assigned are "error value sub-codes"
- list the new sub-codes one per line
- leave out "OAM Problem/" from each one

---

The error value sub-code "Mismatch of BFD Authentication Key ID" in the
IANA section is referred to as "Mismatch of BFD Authentication ID" in
Section 3.3.3 and Section 4.

---

It would be nice to add some material discussing the management impact
of this work. Obviously it is all about OAM, but there are a number of
things that need to be configurable, and a few more things that need to
be visible to a management station.

I'm blocking this I-D pending resolution of my review of draft-ietf-ccamp-rsvp-te-eth-oam-ext. That way I can save a little review time and advance the documents more smoothly.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Proposed Standard as extends GMPLS RSVP-TE protocol. Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This specification describes the configuration of pro-active MPLS-TP
  (MPLS-Transport Profile) Operations, Administration, and Maintenance
  (OAM) Functions for a given LSP using a set of TLVs that are carried
  by the GMPLS RSVP-TE protocol based on [OAM-CONF-FWK].

  This document is a product of a joint Internet Engineering Task Force
  (IETF) / International Telecommunication Union Telecommunication
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and PWE3 architectures to support the
  capabilities and functionalities of a packet transport network.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
No. Good support by the Working Group.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
There have been no public statements, though significant interest
was expressed by the Working Group.
Further questioning of the authors and others associated with this
work reveals that two companies have prototyped this work. The
status of one of those prototypes in unknown, and there are no
announced plans for product.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
Deborah Brungard is the Document Shepherd.
Adrian Farrel is the Area
Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
This document has been adequately reviewed.

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

(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? If so, describe the review that
took place.
No.

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
No 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. If not, explain why.
Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Yes, one related IPR disclosure. No concerns.

(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? 
The WG supported this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
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.
No issues.

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

(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? If such normative
references exist, what is the plan for their completion?
One normative reference to a document pending publication
(draft-ietf-ccamp-oam-configuration-fwk).

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
No change.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Looks appropriate. The IANA section requests consistent codepoint allocation
with draft-ietf-ccamp-oam-configuration-fwk.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
New registries would require Standards Action by CCAMP WG.

(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.
Not applicable.