Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
draft-ietf-ccamp-gmpls-vcat-lcas-13

IANA understands that, upon approval of this document, there are four
IANA Actions that need to be completed.

First, in the Call Attributes TLV subregistry of the Resource
Reservation Protocol (RSVP) Parameters registry located at:

http://www.iana.org/assignments/rsvp-parameters

IANA will register a new Call Attribute TLV as follows:

TLV Value Name Reference
--------- ---------------------- -------------
TBD VCAT_TLV [ RFC-to-be ]

Second, in the Error Codes and Globally-Defined Error Value Sub-Codes
registry in the Resource Reservation Protocol (RSVP) Parameters registry
located at:

http://www.iana.org/assignments/rsvp-parameters

IANA will add a new Error Code as follows:

Error Code: [ TBD ]
Meaning: VCAT Call Management
Reference: [ RFC-to-be ]

and for this Error Code the following Error Values will be registered
(all with a reference of [ RFC-to-be ]:

Meaning Value
------------------------------------ --------
VCG signal type not Supported 1
LCAS option not supported 2
Max number of VCGs exceeded 3
Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5
Unknown LCR (LCAS required) value 6
Unknown or unsupported ACTION 7

Third, IANA will create an entirely new VCAT Elementary Signal Registry
in the Resource Reservation Protocol (RSVP) Parameters registry located at:

http://www.iana.org/assignments/rsvp-parameters

This new registry will be maintained via IETF Review as specified by RFC
5226. The individual registrations in the new registry will include
these parameters:

Value
Type (Elementary Signal)
Reference

The registry will have values between 0 - 65535 inclusive. Value 0
should be marked as Reserved. Other values should be marked Unassigned
(other than the initial values assigned below).

The initial registrations in this registry are as follows (all with a
reference of [ RFC-to-be ]:

Value Type (Elementary Signal)
----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4
11 ODU1 (i.e., 2.5 Gbit/s
12 ODU2 (i.e., 10 Gbit/s)
13 ODU3 (i.e., 40 Gbit/s)
21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps)

Fourth, IANA will create an entirely new VCAT VCG Operation Actions
Registry in the Resource Reservation Protocol (RSVP) Parameters registry
located at:

http://www.iana.org/assignments/rsvp-parameters

This new registry will be maintained via IETF Review as specified by RFC
5226. The individual registrations in the new registry will include
these parameters:

Type
Meaning
Reference

The registry will have values between 0 - 255 inclusive. Other values
should be marked Unassigned (other than the initial values assigned below).

The initial registrations in this registry are as follows (all with a
reference of [ RFC-to-be ]:

Value Meaning
----- ---------------------------------
0 No VCG ID (set up call prior to VCG creation)
1 New VCG for Call
2 Modification of number of members (No Change in VCG ID)
3 Remove VCG from Call

IANA understands that these four actions are the only ones required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Operating Virtual Concatenation (VCAT) and the Link Capacity
  Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
  Switching (GMPLS)'
  as a 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 2011-05-18. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-vcat-lcas/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-vcat-lcas/


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


Abstract

  This document describes requirements for, and use of, the
  Generalized Multi-Protocol Label Switching (GMPLS) control plane in
  support of the Virtual Concatenation (VCAT) layer 1 inverse
  multiplexing data plane mechanism and its companion Link Capacity
  Adjustment Scheme (LCAS) which can be used for hitless dynamic
  resizing of the inverse multiplex group.  These techniques apply to
  Optical Transport Network (OTN), Synchronous Optical Network
  (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous
  Digital Hierarchy (PDH) signals. This document updates RFC 4606 by
  making modifications to the procedures for supporting virtual
  concatenation.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the review
is to catch any nits or issues before the document goes forward to IETF
last call and IESG review. By getting these issues out at this stage we
can hope for a higher quality review and a smoother passage through the
process.

Thank you for a detailed and well-written draft. I have no technical
issues with the content, but a number of small editorial comments and
process-related questions below need to be thought about.

All of my comments are up for discussion, and you should not feel rail-
roaded into making changes. But I do think my comments need to be
addressed before the draft moves forward, and I would like to see your
answers to my points and/or a revised I-D.

I have moved the draft into "AD-review:Revised-ID-needed" state in the
datatracker, and I look forward to seeing the new revision which I can
put forward for IETF last call.

Thanks,
Adrian

---

The header correctly says "Updates: 4606", but the correct format of
this statement is "Updates: 4606 (if approved)"

---

Since the document was first submitted before 10 November 2008, can
the editor confirm that all authors have waived their pre-RFC5378
rights?

---

Abstract
To be more clear about the update of 4606 and to remove the citation
from the abstract, can we...

OLD
  This document updates the procedures for supporting virtual
  concatenation in [RFC4606].
NEW
  This document updates RFC 4606 by making modifications to the
  procedures for supporting virtual concatenation.
END

---

In the Table of Contents, and in the section header...

c/Author's Addresses/Authors' Addresses/

---                                                                                                   

Some acronyms need to be expanded on first use.

TDM
LSR
LSP
NVC

---

Section 2.2

Should you include a definition of "co-routed". This is not quite as
obvious as it might seem since the meanings could be:
- same routers in the same order (includes parallel links)
- same logical links in the same order (includes bundles)
- same data links in the same order (i.e. same physical interfaces)

A bit of this comes out through careful reading of the different
categories, so maybe it is not needed, but it might help.

---

Section 2.2

In "member sharing" are the members required to be co-routed or can
they be diversely routed? I think either. Can you add a note?

---

Section 2.3

    .  GMPLS signaling for non-LCAS-capable interfaces MUST support
        only the "fixed" scenarios of section 2.2.

This appears to say:
  MUST NOT support the "dynamic" scenarios.
If you mean that, can you reword accordingly.

On the other hand, it is also possible you mean:
  MUST support the "fixed" scenarios and MAY also support the "dynamic"
  scenarios.

---

Section 4

I agree that it is right to include this section, but I would like you
to make it clearer that 4606 is normative. How about...

OLD
  Note that this section is included for informational
  purposes only.
NEW
  Note that this section is included for informational
  purposes only and does not modify [RFC4606]. It is provided to
  show how the existing GMPLS procedures may be used. [RFC4606]
  provides the normative definition for GMPLS processing of VCGs
  composed of a single member set, and in the event of any
  conflict between this section and that document, [RFC4606]
  takes precedence.
END

---

Section 4.3

  Note if using LCAS, a VCG member can be temporary removed from the
  VCG due to a failure of the component signal. The LCAS data plane
  signaling will take appropriate actions to adjust the VCG as
  described in [ITU-T-G.7042].

s/temporary/temporarily/

---

Figure 1 caption

    Figure 1 Figure 1. Conceptual containment relationship between VCG,
        VCAT calls, control plane LSPs, and data plane connections.

"Figure 1" appears twice

---

Section 5.2

Given that "Number of Members" is a two octet integer, you need to
mention the byte order on the wire.

---

Section 5.2

I'm a bit surprised that you have used a whole 8 bits for "LCAS
Required". Probably not important, but you could carve out some
spare bits for future extensions without changing the format.

---

Section 5.2

Should you also have a registry for the Elementary Signal Types listed
in this section? it seems likely that there will be future additions to
the list. You should say that unlisted values are reserved and you
should say what the allocation policy is for future values.

The same applies to "Action" since future actions might show up.

---

Section 6 might need to note error cases for unknown "LCAS Required"
setting (perhaps this can be noted as a malformed message and result in
a standard result code?) and unknown or unsupported "Action" (I suggest
that this is another instance for your list because some of the actions
might not be supported by an implementation, and new actions may be
defined.)

---

Section 7.1

I suggest you remove the suggested value (2) from the document.
Suggesting values is pretty risky for implementers and in this case
your suggested value clashes with RFC 6004.

---

Section 8

I suggest you add one additional paragraph to this section.

  See [RFC5920] for additional information on GMPLS security.

And (obviously) add an Informative Reference to 5920

---

You can probably delete the final line...

"Acknowledgment"

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Deborah Brungard is the Document Shepherd.

She has reviewed the document and believes it is ready for
forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been adequately reviewed. In addition, it was
liaisoned
with ITU-T. Two WG Last Calls were held to ensure adequate review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns or issues. No IPR found in the datatracker.

(1.e) 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?

There is good consensus behind this document.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate
Checks are not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Split looks okay.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA section looks good.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes, no automated checks needed.

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in support of
the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data
plane mechanism and its companion Link Capacity Adjustment Scheme
(LCAS) which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to Optical Transport Network
(OTN), Synchronous Optical Network (SONET), Synchronous Digital
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.
This document updates the procedures for supporting virtual
concatenation in [RFC4606].

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?

This document received much attention and discussion in its early
revisions.
The document has been stable for quite some time, mainly needing
revisions as
part of the publication process.

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 related to implementations.