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
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
13 | (System) | Notify list changed from ccamp-chairs@ietf.org, draft-ietf-ccamp-gmpls-vcat-lcas@ietf.org to (None) |
2012-01-31
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6344 | |
2012-01-09
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ccamp-gmpls-vcat-lcas-14 | |
2011-08-19
|
13 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-08-19
|
13 | (System) | RFC published |
2011-07-22
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-07-22
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-07-22
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-07-22
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-06-14
|
13 | (System) | IANA Action state changed to In Progress |
2011-06-13
|
13 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-06-13
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-06-13
|
13 | Amy Vezza | IESG has approved the document |
2011-06-13
|
13 | Amy Vezza | Closed "Approve" ballot |
2011-06-09
|
13 | Adrian Farrel | Ballot writeup text changed |
2011-06-09
|
13 | Adrian Farrel | Ballot writeup text changed |
2011-06-09
|
13 | Adrian Farrel | Approval announcement text changed |
2011-06-09
|
13 | Adrian Farrel | Approval announcement text regenerated |
2011-06-09
|
13 | Cindy Morgan | Removed from agenda for telechat |
2011-06-09
|
13 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
2011-06-09
|
13 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-09
|
13 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-09
|
13 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-08
|
13 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-08
|
13 | Russ Housley | [Ballot comment] The Gen-ART Review by Kathleen Moriarty on 7-Jun-2011 includes several editorial improvements. Please consider them. |
2011-06-08
|
13 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-08
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-07
|
13 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-07
|
13 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-07
|
13 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-07
|
13 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-07
|
13 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-03
|
13 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-03
|
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Ondřej Surý. |
2011-05-26
|
13 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-18
|
13 | Amanda Baber | 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 … 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. |
2011-05-18
|
13 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2011-05-18
|
13 | Adrian Farrel | Ballot has been issued |
2011-05-18
|
13 | Adrian Farrel | Created "Approve" ballot |
2011-05-18
|
13 | Adrian Farrel | Placed on agenda for telechat - 2011-06-09 |
2011-05-18
|
13 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-05-18
|
13 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-05-07
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2011-05-07
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2011-05-04
|
13 | Cindy Morgan | Last call sent |
2011-05-04
|
13 | Cindy Morgan | 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: … 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. |
2011-05-04
|
13 | Adrian Farrel | Last Call was requested |
2011-05-04
|
13 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2011-05-04
|
13 | Adrian Farrel | Last Call text changed |
2011-05-04
|
13 | (System) | Ballot writeup text was added |
2011-05-04
|
13 | (System) | Last call text was added |
2011-05-04
|
13 | (System) | Ballot approval text was added |
2011-05-04
|
13 | Adrian Farrel | Ballot writeup text changed |
2011-05-04
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-04
|
13 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-13.txt |
2011-05-03
|
13 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup. |
2011-05-02
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-02
|
12 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-12.txt |
2011-04-29
|
13 | Adrian Farrel | 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 … 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" |
2011-04-29
|
13 | Adrian Farrel | State changed to AD Evaluation from Publication Requested. |
2011-04-26
|
13 | Cindy Morgan | (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 … (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. |
2011-04-26
|
13 | Cindy Morgan | Draft added in state Publication Requested |
2011-04-26
|
13 | Cindy Morgan | [Note]: 'Deborah Brungard (dbrungard@att.com) is the document shepherd.' added |
2011-03-09
|
11 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-11.txt |
2011-01-13
|
13 | (System) | Document has expired |
2010-07-12
|
10 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-10.txt |
2010-01-11
|
09 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-09.txt |
2009-07-29
|
08 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-08.txt |
2008-12-18
|
07 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-07.txt |
2008-11-18
|
06 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-06.txt |
2008-07-08
|
05 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt |
2008-02-08
|
04 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-04.txt |
2007-10-04
|
03 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-03.txt |
2007-04-02
|
02 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-02.txt |
2006-10-22
|
01 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-01.txt |
2006-09-08
|
00 | (System) | New version available: draft-ietf-ccamp-gmpls-vcat-lcas-00.txt |