GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-13

[Ballot comment]
I have only given this a quick look over and there is nothing here that bothers me from an applications area perspective.

I would suggest a good scrub of what may or may not (no pun intended) be interoperability requirements text. There are many "must"s that appear to be very much about interoperability requirements and many "MUST"s that appear to not be. They seem randomly sprinkled. A review seems in order.

[Ballot comment]
I agree with Stephen on the nesting problem for the security considerations.  Since RFC6060 points out that a hostile environment should be assumed, it would be good to mention other security protections with the appropriate links directly in the security considerations section of this document.

[Ballot comment]

- section 2, para 2: the meaning of "co-routed" wasn't
entirely clear to me, but I think that's probably ok if what
you mean is the DA from one is the SA from the other and
vice-versa.  If it means something else, (e.g. that packets
from DA to SA must traverse the same links as from SA to DA)
that would be worth saying, or it would be worth referring
to some document that defines co-routed more fully.

- Table 1: You don't say what "reserved" means, but asssume
it means "do not use"?

- section 2, last para: I wondered what "subset" you meant
for MIPs.

- 3.1: I was surprised that so much is left for local
config, in particular the CCM Interval - am I right that
if you have different intervals setup then one of the
MEPs will be constantly calling the LSP broken because
CCM messages/frames won't arrive on time? (Though I see
in 3.3.4 that you can send this info from one to the
other, but I don't see where it says what to do with
that value on receipt.)

- 3.3.x, I hope IANA notice they're being asking for
something (or you repeat it later)

- 3.3.3: what if received a MEP ID is >=8192? (e.g. 2^14)
(I also wondered why you want to save 3 bits but don't
just reserve them)

- 3.4: "PM" confused me briefly (cf. RFC7258:-)

- section 5: defers to [OAM-CONF-FWK] - which draft is that?
(I'm guessing
https://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk
right?) And to RFC6060 which defers to RFC4872 which
eventually says that "RSVP signaling MUST be able to provide
authentication and integrity" - does that latter apply here?
If so, (which I assume since that's a normative ref)
wouldn't it be nice to remove the double indirection and
just point that out directly.

Hi authors,

It looks like you have some work to do to address comments from:
- Young Lee (routing Directorate)
- Scott Brim (just a nit)
- Amanda Barber (for IANA).

I'll watch for emails and possibly a revised I-D.

Thanks,
Adrian

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ccamp-rsvp-te-eth-oam-ext-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about at least one of the actions requested in the IANA Considerations section of this document.

IANA also is aware that some of the IANA actions requested in this document are dependent on the approval of other documents.

IANA understands that, upon approval of this document, there are five actions which IANA must complete.

First, the document refers to a registry to be created by another document entitled "OAM Configuration Framework for GMPLS RSVP-TE." However, IANA is unable to find such a document in the IETF Datatracker, and this document's reference section does not include a draft string.. There is a document titled "GMPLS RSVP-TE extensions for OAM Configuration" in the RFC editor queue, and IANA wonders if this is the document that is supposed to be in the normative references.

IANA Question -> is the document in the normative references which is listed as "OAM Configuration Framework for GMPLS RSVP-TE" actually supposed to be "GMPLS RSVP-TE extensions for OAM Configuration?"

Second, if the "RSVP-TE OAM Configuration Registry" is the one created by the approval of "GMPLS RSVP-TE extensions for OAM Configuration," then IANA will register this value in the OAM Types registry:

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

IANA notes that the authors have suggested that the value of 1 be used for this registration.

Third, IANA notes that the "OAM Sub-TLVs Sub-Registry" of the "RSVP-TE OAM Configuration Registry" is also created by the approval of "GMPLS RSVP-TE extensions for OAM Configuration."

In that sub-registry, a new Sub-TLV is to be created as follows:

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

This value must be registered from the technology-specific range of the "OAM Sub-TLVs Sub-Registry" of the "RSVP-TE OAM Configuration Registry." IANA notes that the authors have suggested that the value of 32 be used for this registration.

Fourth, a new registry is to be created in the "RSVP-TE OAM Configuration Registry" created by the approval of the document "GMPLS RSVP-TE extensions for OAM Configuration." The new registry will be called the "Ethernet Sub-TLVs Sub-Registry."

IANA understands that the registration rules (referring to RFC 5226) for the new sub-registry are as follows:

Range | Registration Procedures
------------+----------------------------
0-65534 | IETF Review
65535-65536 | Experimental

IANA understands that there will be initial registrations in the sub-registry as follows:

Sub-TLV Type | Description | Reference
--------------------------------------------------------
0 | Reserved | [ RFC-to-be ]
1 | MD Name Sub-TLV | [ RFC-to-be ]
2 | Short MA Name Sub-TLV | [ RFC-to-be ]
3 | MEP ID Sub-TLV | [ RFC-to-be ]
4 | Continuity Check Sub-TLV | [ RFC-to-be ]
5-65536 | Unassigned | [ RFC-to-be ]

Fifth, IANA notes that a new Error Code, "OAM Problem" in the "Error Codes and Globally-Defined Error Value Sub-Codes" registry in "Resource Reservation Protocol (RSVP) Parameters," is also created by the approval of "GMPLS RSVP-TE extensions for OAM Configuration." (See Section 5.4 of that document.)

IANA understands that, upon approval of this document, new error value sub-codes are to be added to the registry "OAM Problem Subcodes "created by the approval of "GMPLS RSVP-TE extensions for OAM Configuration." (see Section 5.4 of that document). These new values are as follows:

Value | Description | Reference
------+---------------------------+--------------
TBA | Unsupported OAM Version | [ RFC-to-be ]
TBA | Unsupported MD Level | [ RFC-to-be ]
TBA | Unknown MD Name Format | [ RFC-to-be ]
TBA | Unknown MA Name Format | [ RFC-to-be ]
TBA | Name Length Problem | [ RFC-to-be ]
TBA | Unsupported CC Interval | [ RFC-to-be ]

IANA understands that these five actions are the only ones required 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (GMPLS RSVP-TE Extensions for Ethernet OAM Configuration) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'GMPLS RSVP-TE Extensions for Ethernet OAM Configuration'
  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 2014-04-15. 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

  The GMPLS controlled Ethernet Label Switching (GELS) work extended
  GMPLS RSVP-TE to support the establishment of Ethernet LSPs.  IEEE
  Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
  flow to check connectivity in Ethernet networks.  CFM can be also
  used with Ethernet LSPs for fault detection and triggering recovery
  mechanisms.  The ITU-T Y.1731 specification builds on CFM and
  specifies additional OAM mechanisms, including Performance
  Monitoring, for Ethernet networks.  This document specifies
  extensions of GMPLS RSVP-TE protocol to support the setup of the
  associated Ethernet OAM entities of Ethernet LSPs, and defines the
  Ethernet technology specific TLVs based on the GMPLS OAM
  Configuration Framework.  This document supports, but does not
  modify, the IEEE and ITU-T OAM mechanisms.

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

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


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

  http://datatracker.ietf.org/ipr/1380/
  http://datatracker.ietf.org/ipr/895/

AD review
========

Hi,

Thanks to the authors for engaging with me on the implementation
status and plans for this document.

The CCAMP OAM configuration framework draft has 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

===

Section 3.1 says

"procedures are recommended as follows" and then goes on to say "MUST"

That reads oddly.
I think you can just s/are recommended as follows/are as follows/

---

I think you have the Length in the TLVs messed up.
For example, in 3.3 you have
  Length: indicates the total length including sub-TLVs.
"Total length implies "including the T and L fields".
And in 3.3.1 and 3.3.2 you have
  Length: indicates the total length of the TLV including padding.
which has a similar implication.
Yet in 3.3.3 while you still have
  Length: indicates the total length of the TLV including padding.
the figure shoes "Length (4)"

Please update all descriptions of Length to say (depending on your
intention) either:

  Length: indicates the total length of the TLV including padding
          and including the Type and Length fields

or

  Length: indicates the total length of the TLV including padding
          but excluding the Type and Length fields

And then, obviously, check any explicit values in the text.

---

In Section 3.3.4 you have assigned 4 bits for each of the Priority and
CCM I fields.

Yet the text describes how these may be mapped directly to the
equivalent Ethernet fields each of which is described as being 3 bits.

Why is there this discrepancy and how will the top bit be used?

---

The IANA section needs some work.

First I suggest you break it into subsections to clearly show each
different registry being updated.

Then we need some additional text as follows:

- The RSVP-TE OAM Configuration Registry doesn't exist yet so you need
  to provide IANA with a reference using text like "[OAM-CONF-FWK]
  includes a request for IANA to create the RSVP-TE OAM Configuration
  Registry". IANA is requested to assign an OAM Type from this
  registry as follows.

  Similar thing for the sub-TLV type.

- For the sub-TLV you need to tell IANA that the value is to be allocated
  from the technology-specific range

- You need to not state specific values unless you have a strong reason
  for doing so or the values have already been assigned through early
  allocation.

  Replace "1" with TBA1
  Replace "32" with TBA2
  Go through the main body of the text and make these replacements as
  well

  Then add text that says:
    The value of 1 is suggested for TBA1
    The value of 32 is suggested for TBA2

- The term "reserved" has a special meaning in IANA registries. It means
  "do not allocate". So I think you do not want to use that term in your
  new registry!

  Well, 0 may be genuinely reserved, but "5-" should probably read
  "unassigned"

- You need to indicate the maximum legitimate value for the code points
  in the new registry. So replace "5-" with "5-x" where x is the max
  value (governed by the size of the Type field?)

- You need to state the RFC 5226 assignment policy for the new registry.
  Probably "Standards Action", but you may have other ideas. Should any
  of the code points be reserved for Experimentation?

- "OAM Problem"
  - You need to tell IANA which registry you are talking about
  - The return code doesn't exist yet, so you need to include a
    reference to [OAM-CONF-FWK]

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

  The GMPLS controlled Ethernet Label Switching (GELS) work extended
  GMPLS RSVP-TE to support the establishment of Ethernet LSPs.  IEEE
  Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
  flow to check connectivity in Ethernet networks.  CFM can be also
  used with Ethernet LSPs for fault detection and triggering recovery
  mechanisms.  The ITU-T Y.1731 specification builds on CFM and
  specifies additional OAM mechanisms, including Performance
  Monitoring, for Ethernet networks.  This document specifies
  extensions of GMPLS RSVP-TE protocol to support the setup of the
  associated Ethernet OAM entities of Ethernet LSPs, and defines the
  Ethernet technology specific TLVs based on [OAM-CONF-FWK].  This
  document supports, but does not modify, the IEEE and ITU-T OAM
  mechanisms.


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 reveals that two companies have
prototyped this work although there are currently 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, two related IPR disclosures. 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.

(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

  The GMPLS controlled Ethernet Label Switching (GELS) work extended
  GMPLS RSVP-TE to support the establishment of Ethernet LSPs.  IEEE
  Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
  flow to check connectivity in Ethernet networks.  CFM can be also
  used with Ethernet LSPs for fault detection and triggering recovery
  mechanisms.  The ITU-T Y.1731 specification builds on CFM and
  specifies additional OAM mechanisms, including Performance
  Monitoring, for Ethernet networks.  This document specifies
  extensions of GMPLS RSVP-TE protocol to support the setup of the
  associated Ethernet OAM entities of Ethernet LSPs, and defines the
  Ethernet technology specific TLVs based on [OAM-CONF-FWK].  This
  document supports, but does not modify, the IEEE and ITU-T OAM
  mechanisms.


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.

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, two related IPR disclosures. 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.