Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
RFC 7581
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
28 | (System) | Received changes through RFC Editor sync (changed abstract to 'A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate ... Received changes through RFC Editor sync (changed abstract to 'A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).') |
2017-05-16 |
28 | (System) | Changed document authors from "Dan Li, Greg Bernstein, Wataru Imajuku, Young Lee" to "Dan Li, Greg Bernstein, Wataru Imajuku, Young Lee, Jianrui Han" |
2015-10-14 |
28 | (System) | Notify list changed from ccamp-chairs@ietf.org, draft-ietf-ccamp-rwa-wson-encode@ietf.org to (None) |
2015-06-30 |
28 | (System) | IANA registries were updated to include RFC7581 |
2015-06-25 |
28 | (System) | RFC published |
2015-06-23 |
28 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-06-04 |
28 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-05-27 |
28 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2015-05-22 |
28 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-03-26 |
28 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-25 |
28 | Amy Vezza | Shepherding AD changed to Deborah Brungard |
2015-03-25 |
28 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2015-03-25 |
28 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-03-21 |
28 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-03-18 |
28 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-03-10 |
28 | (System) | IANA Action state changed to In Progress |
2015-03-09 |
28 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-03-09 |
28 | (System) | RFC Editor state changed to EDIT |
2015-03-09 |
28 | (System) | Announcement was received by RFC Editor |
2015-03-09 |
28 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-03-09 |
28 | Amy Vezza | IESG has approved the document |
2015-03-09 |
28 | Amy Vezza | Closed "Approve" ballot |
2015-03-09 |
28 | Amy Vezza | Ballot approval text was generated |
2015-03-09 |
28 | Amy Vezza | Ballot writeup was changed |
2015-03-05 |
28 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2015-03-05 |
28 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-03-05 |
28 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-03-05 |
28 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-03-05 |
28 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-03-05 |
28 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-03-05 |
28 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-03-04 |
28 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-03-04 |
28 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-03-04 |
28 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-03-04 |
28 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-03-03 |
28 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-03-02 |
28 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. |
2015-03-02 |
28 | Peter Yee | Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee. |
2015-02-26 |
28 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2015-02-25 |
28 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2015-02-25 |
28 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2015-02-25 |
28 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-02-25 |
28 | Adrian Farrel | Ballot has been issued |
2015-02-25 |
28 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2015-02-25 |
28 | Adrian Farrel | Created "Approve" ballot |
2015-02-25 |
28 | Adrian Farrel | Ballot writeup was changed |
2015-02-24 |
28 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-24 |
28 | Young Lee | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2015-02-24 |
28 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-28.txt |
2015-02-23 |
27 | Adrian Farrel | Placed on agenda for telechat - 2015-03-05 |
2015-02-23 |
27 | Adrian Farrel | Changed consensus to Yes from Unknown |
2015-02-23 |
27 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2015-02-20 |
27 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
2015-02-19 |
27 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-02-17 |
27 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-02-17 |
27 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ccamp-rwa-wson-encode-27. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon ... IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ccamp-rwa-wson-encode-27. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has a question about the action requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there is a single action that IANA must complete. This document requests that a new registry be created. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? Is it to be a subregistry of the GMPLS Signaling Parameters registry? The new registry is to be called the Types for subfields of WSON Resource Block Information registry. The new registry will be maintained via Standards Action as defined by RFC 5226. There are initial values in the new registry as follows: Value Length Sub-TLV Type Reference 0 Reserved 1 variable Optical Interface Class List [ RFC-to-be ] 2 variable Acceptable Client Signal List [ RFC-to-be ] 3 variable Input Bit Rate List [ RFC-to-be ] 4 variable Processing Capability List [ RFC-to-be ] 5-65535 Unassigned IANA understands that this action is the only one 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. |
2015-02-12 |
27 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2015-02-12 |
27 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2015-02-10 |
27 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Fajardo |
2015-02-10 |
27 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Fajardo |
2015-02-05 |
27 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2015-02-05 |
27 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2015-02-05 |
27 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-02-05 |
27 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <ccamp@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-ccamp-rwa-wson-encode-27.txt> ... The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <ccamp@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-ccamp-rwa-wson-encode-27.txt> (Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks) to Proposed Standard The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks' <draft-ietf-ccamp-rwa-wson-encode-27.txt> 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-02-19. 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 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-02-05 |
27 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2015-02-05 |
27 | Adrian Farrel | Last call was requested |
2015-02-05 |
27 | Adrian Farrel | Ballot approval text was generated |
2015-02-05 |
27 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-02-05 |
27 | Adrian Farrel | Last call announcement was changed |
2015-02-05 |
27 | Adrian Farrel | Last call announcement was generated |
2015-02-05 |
27 | Adrian Farrel | Write up for draft-ietf-ccamp-rwa-wson-encode > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are ... Write up for draft-ietf-ccamp-rwa-wson-encode > 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)? Standards Track > Why is this the proper type of RFC? The document defines encodings (wire formats) for use in routing and signaling protocols. > Is this type of RFC indicated in the title page header? 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 > > 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 provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). > 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 topic been discussed in the WG for a very long time, perhaps 6 years. Support for the work has been tepid, but there are multiple sets of contributors who would like to see the work result in proposed standards. A late discussion about the inclusion of vendor-specific information went back to the WG list and resulted in the removal of such TLVs until the ITU-T has completed its work in this area. > 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? This document provides background and an approach to extending exiting RFCs for which there are implementations, but does not itself define any protocol mechanisms. The existing RFCs include RFC3471, RFC3473, RFC4202, RFC4203. This work is based on RFC6163. > Personnel > > Who is the Document Shepherd? Lou Berger > Who is the Responsible Area Director? Adrian Farrel > (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. The Document Shepherd has reviewed the document as it has progressed through the CCAMP WG, including as part of an extended WG last calls. The Shepherd believes this document is ready for publication. This document is part of a set of documents on WSON and final publication -- and at the AD's discretion, IETF LC -- should occur as a set. The documents set includes: draft-ietf-ccamp-rwa-info draft-ietf-ccamp-general-constraint-encode draft-ietf-ccamp-rwa-wson-encode draft-ietf-ccamp-gmpls-general-constraints-ospf-te draft-ietf-ccamp-wson-signal-compatibility-ospf draft-ietf-ccamp-wson-signaling > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No. > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. As part of the 2nd WG LC, both the OSPF WGs chairs were consulted. (But didn't offer any input.) > (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 specific 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, via messages to/on the CCAMP WG list. > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. No IPR has been disclosed for this document. > (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? Good among interested parties. No objections from others. > (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.) Not to my knowledge. > (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. The document passes tools idnits. > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. > (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? None. > (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. None. > (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. > (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). This document introduces a new registry for GMPLS routing parameters for WSON encoding. This new IANA registry will be created to make the assignment of a new type and new values for the new "GMPLS Routing Parameters for WSON. > (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. One new "GMPLS Routing Parameters for WSON" registry is defined. Types are to be assigned via Standards Action as defined in [RFC5226]. > (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. N/A. |
2015-02-05 |
27 | Adrian Farrel | Ballot writeup was changed |
2015-02-04 |
27 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-04 |
27 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-27.txt |
2015-01-02 |
26 | Adrian Farrel | AD review ====== Hello, I've now done my AD review of this document. I am rather regretting starting the IETF last call for draft-ietf-ccamp-general-constraint- encode ... AD review ====== Hello, I've now done my AD review of this document. I am rather regretting starting the IETF last call for draft-ietf-ccamp-general-constraint- encode on which this document depends because it seems that this document introduces WSON-specific encodings (all of those before Section 4) that should/could have been made generic. In fact, I thought the point of the general encodings document was to produce protocol objects that could be used by technology-specific documents like this one. If you can respond to my comments below, we can work out whether the general encodings document needs to be brought back for more work. Thanks for your efforts with this. Adrian =========== Abstract while other parts are fairly specific to WSONs. They are either specific or they are not. I think you need s/fairly specific/specific/ --- Shouldn't the Introduction include a discussion of and reference to [Gen-encode]? --- The Introduction has This document provides efficient encodings and Note that since these encodings are relatively efficient Which are they? And relative to what? --- Section 1.1 has Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool. I think you mean [RWA-Info]. That would also make [RWA-Info] a normative reference which seems correct anyway. --- Section 1.1 makes RFC 6163 a normative reference. --- Section 2.1 seems somewhere between a copy of and a modification of the Link Set Field in 2.3 of [Gen-Encode]. Some clarification would be useful. If this is different, why is it not using one of the generic encodings applied in a specific way? If it is the same, you should probably just reference the encoding in [Gen-Encode] and describe here how the fields are used, but if you insist in re-drawing the figure it should be aligned with the figure in [Gen-Encode]. --- Section 2.1 The RB identifier represents the ID of the resource block which is a 32 bit integer. You might note that the scope of the RB identifier is local to the node on which it is applied although that node may choose to use a globally known encoding such as from RFC 6205. I assume that flexi-grid is out of scope for WSON. If it is not, then you need to think further about your 32 bit identifiers. --- Section 3.1 Why isn't the Resource Accessibility Field expressed in terms of the use of a generic Connectivity Matrix Field from section 2.1 of [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive application agnostic encodings that could be used without modification (but with applicability notes) by specific technologies. --- Section 3.2 I looked for the equivalent of the Resource Wavelength Constraints Field in [Gen-Encode]. I understand that Input Wavelength Constraints Field and Output Wavelength Constraints Field are encoded using the generic Label Set of [Gen-Encode], but I thought that the whole concept of Resource Constraints would be generic. --- Section 3.3 As with the previous section I don't see anything that is WSON-specific in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field and I wondered why [Gen-Encode] doesn't have anything to cover this. --- Section 3.3 Where Action = 0 denotes a list of 16 bit integers and Action = 1 denotes a bit map. In both cases the elements of the RB Set field are in a one-to-one correspondence with the values in the usage RB usage state area. This is not clear. I think the Action field is explaining how the RB Usage State field is encoded. - Not sure why you call it "Action" - Would be good if you could make it clear that "16 bit integers" or "bit map" apply to the RB Usage State field. But... RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. - You might say what value of the 16 bit unsigned integer indicates in use and what value indicates available. - You should explain to me why a list of 16 bit integers to encode a set of Booleans is in anyway efficient or appropriate. It is *really* hard to parse from this section that the state applies to the whole RB when Action is 0, but applies to the elements of the RBs when Action is 1. At least, that is what I think I parsed from the text although I also found text in the section that convinced me you meant something else. In short, this section is not clear! --- Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? --- Sections 3.4 and 4 should list the allowed settings of I and O (presumably: 01, 10, 11). Cf. Section 3.2. --- Section 4 How do I know the length of the ResourceBlockInfo field? I need to know this to decide whether to try to parse the next bytes as another Optional subfield. I *do* when I reach the end of one Optional subfield, but I don't know whether another follows. Possibly you intend the object that includes a ResourceBlockInfo field to provide the length information, but other fields defined in this document do include lengths or enough information to deduce the lengths. --- Section 4.1 The following I and E combination are defined: s/E/O/ --- Section 4.1 1: [ITU-G.698.1] application code. 2: [ITU-G.698.2] application code. 3: [ITU-G.959.1] application code. 4: [ITU-G.695] application code. You should use the same format as in the references section. E.g., [G.959.1]. Do you mean 698 or 694? You have references for 694.1 and 694.2, but not 698.1 or 698.2. But 694.1 does not seem to include any "application codes" - they're in 698.1 and 698.2. Each of the subsections 4.1.1-4.1.4 should include a citations. --- Section 4.1 How do I interpret a Vendor-Specific Application Code? Is there an OUI I'm missing? --- I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and have asked the chairs to send a liaison to ITU-T Q6/15 asking them to cast an eye over the text of these sections. --- 4.1.1 Where (values between parenthesis refer to ITU defined values as reported above): Please remove the parentheses from this sentence. --- 4.1.1 and 4.1.2 An Optional F can be added indicating a FEC Encoding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| D |S| c | W | y | t | z | v | F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F (suffix): = 0 reserved, = 1 Fec Encoding Values not mentioned here are not allowed in this application code If F is optional but only one value is allowed (viz. 1) how do I opt to not indicate a FEC Encoding? --- 4.1.1 and 4.1.2 Your definition of parameter c makes RFC 6205 a normative reference. . I think you could usefully point with more precision to Figure 2 in Section 3.2 of RFC 6205. However, I wonder whether you want to allow new values that may be added to the IANA registry created by Section 5.2 of RFC 6205 --- 4.1.3 and 4.1.4 n: maximum number of channels (10 bits, up to 1024 channels) Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that n=0 is not valid and so n is actually max channels minus one. --- 4.4 The processing capability list field is then given by: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Processing Cap ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional capability parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the processing ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the processing Cap ID is "regeneration capability", the I don't believe you have told me how to encode "regeneration capability" into the Processing Cap ID field. Possibly you mean that the numbered list above is intended to define the settings of this field. If so then: - say so - explain that "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters - probably remove the note about "Fault and performance monitoring" and "vendor specific capability" because if it isn't here it is, of course, for future study. --- 4.4 Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as input and output restrictions and availability need to be specified. The code point for this is subject to further study. I think you mean to replace that final line with... These properties will be encoded in the capabilities field starting with the bits marked Reserved in the figure. An additional specification describing the encoding of these parameters is required before the value C=2 can be used. --- Section 6 In Section 6 and 6.1 you appear to be creating a new top-level registry called "GMPLS Routing Parameters for WSON" with a sub-registry called "Types for subfields of WSON Resource Block Information". It's a shame to create a whole new top-level registry. I suppose you think that this information will only ever be used in routing and never in signaling. Probably right, in which case you are good to go, although your text could be clearer. --- Section A.3 is using some form of BNF to represent information. This is probably RBNF from RFC 5511. Anyway, you need to give a reference so people can read it. It would be nice to lay the BNF out on the page in a more readable way. |
2015-01-02 |
26 | Adrian Farrel | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2014-12-31 |
26 | Adrian Farrel | Ballot writeup was changed |
2014-12-31 |
26 | Adrian Farrel | Ballot writeup was generated |
2014-12-28 |
26 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-09-30 |
26 | Lou Berger | Write up for draft-ietf-ccamp-rwa-wson-encode > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are ... Write up for draft-ietf-ccamp-rwa-wson-encode > 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)? Standards Track > Why is this the proper type of RFC? The document defines encodings (wire formats) for use in routing and signaling protocols. > Is this type of RFC indicated in the title page header? 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 > > 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 provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). > 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 topic been discussed in the WG for a very long time, perhaps 6 years. Support for the work has been tepid, but there are multiple sets of contributors who would like to see the work result in proposed standards. > 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? This document provides background and an approach to extending exiting RFCs for which there are implementations, but does not itself define any protocol mechanisms. The existing RFCs include RFC3471, RFC3473, RFC4202, RFC4203. This work is based on RFC6163. > Personnel > > Who is the Document Shepherd? Lou Berger > Who is the Responsible Area Director? Adrian Farrel > (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. The Document Shepherd has reviewed the document as it has progressed through the CCAMP WG, including as part of an extended WG last calls. The Shepherd believes this document is ready for publication. This document is part of a set of documents on WSON and final publication -- and at the AD's discretion, IETF LC -- should occur as a set. The documents set includes: draft-ietf-ccamp-rwa-info draft-ietf-ccamp-general-constraint-encode draft-ietf-ccamp-rwa-wson-encode draft-ietf-ccamp-gmpls-general-constraints-ospf-te draft-ietf-ccamp-wson-signal-compatibility-ospf draft-ietf-ccamp-wson-signaling > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? No. > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. As part of the 2nd WG LC, both the OSPF WGs chairs were consulted. (But didn't offer any input.) > (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 specific 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, via messages to/on the CCAMP WG list. > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. No IPR has been disclosed for this document. > (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? Good among interested parties. No objections from others. > (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.) Not to my knowledge. > (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. The document passes tools idnits. > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. > (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? None. > (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. None. > (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. > (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). This document introduces a new registry for GMPLS routing parameters for WSON encoding. This new IANA registry will be created to make the assignment of a new type and new values for the new "GMPLS Routing Parameters for WSON. > (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. One new "GMPLS Routing Parameters for WSON" registry is defined. Types are to be assigned via Standards Action as defined in [RFC5226]. > (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. N/A. |
2014-09-30 |
26 | Lou Berger | State Change Notice email list changed to ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org |
2014-09-30 |
26 | Lou Berger | Responsible AD changed to Adrian Farrel |
2014-09-30 |
26 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2014-09-30 |
26 | Lou Berger | IESG state changed to Publication Requested |
2014-09-30 |
26 | Lou Berger | IESG process started in state Publication Requested |
2014-09-30 |
26 | Lou Berger | Changed document writeup |
2014-09-30 |
26 | Lou Berger | Changed document writeup |
2014-09-30 |
26 | Lou Berger | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2014-09-30 |
26 | Lou Berger | Intended Status changed to Proposed Standard from None |
2014-05-21 |
26 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-26.txt |
2014-05-21 |
25 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-25.txt |
2014-02-13 |
24 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-24.txt |
2013-11-13 |
23 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-23.txt |
2013-11-12 |
22 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-22.txt |
2013-10-31 |
21 | Lou Berger | Only waiting for LC comments to be addressed. All IPR disclosures have been made. |
2013-10-31 |
21 | Lou Berger | IETF WG state changed to Waiting for WG Chair Go-Ahead from Waiting for WG Chair Go-Ahead |
2013-10-31 |
21 | Lou Berger | Waiting for LC comments to be addressed, and on IPR declaration to be made. |
2013-10-31 |
21 | Lou Berger | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2013-10-30 |
21 | Daniele Ceccarelli | WG last call comments http://www.ietf.org/mail-archive/web/ccamp/current/msg15426.html http://www.ietf.org/mail-archive/web/ccamp/current/msg15428.html |
2013-10-30 |
21 | Daniele Ceccarelli | IETF WG state changed to In WG Last Call from In WG Last Call |
2013-10-30 |
21 | Daniele Ceccarelli | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2013-10-28 |
21 | Lou Berger | Document shepherd changed to Lou Berger |
2013-10-15 |
21 | Daniele Ceccarelli | http://www.ietf.org/mail-archive/web/ccamp/current/msg15347.html |
2013-10-15 |
21 | Daniele Ceccarelli | IETF WG state changed to In WG Last Call from WG Document |
2013-10-15 |
21 | Daniele Ceccarelli | Annotation tag Other - see Comment Log cleared. |
2013-09-30 |
21 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-21.txt |
2013-09-26 |
20 | Daniele Ceccarelli | IPR declarations at September 27th 2013: -All received ggalimbe at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15320.html) imajuku.wataru at lab.ntt.co.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg15305.html) hanjianrui at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15314.html ... IPR declarations at September 27th 2013: -All received ggalimbe at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15320.html) imajuku.wataru at lab.ntt.co.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg15305.html) hanjianrui at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15314.html) |
2013-09-26 |
20 | Daniele Ceccarelli | IETF WG state changed to WG Document from WG Document |
2013-09-16 |
20 | Daniele Ceccarelli | IPR declarations at September 16th 2013: -Still missing: ggalimbe at cisco.com(...) imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) - Received: anders.gavler at acreo.se ... IPR declarations at September 16th 2013: -Still missing: ggalimbe at cisco.com(...) imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) - Received: anders.gavler at acreo.se (http://www.ietf.org/mail-archive/web/ccamp/current/msg15090.html), jonas.martensson at acreo.se(http://www.ietf.org/mail-archive/web/ccamp/current/msg15094.html) gregb at grotto-networking.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15254.html) pierre.peloso at alcatel-lucent.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15259.html) |
2013-09-16 |
20 | Daniele Ceccarelli | IETF WG state changed to WG Document from WG Document |
2013-08-12 |
20 | Daniele Ceccarelli | IPR declarations at August 12th 2013: -Still missing: pierre.peloso at alcatel-lucent.com(...) ggalimbe at cisco.com(...) imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) - ... IPR declarations at August 12th 2013: -Still missing: pierre.peloso at alcatel-lucent.com(...) ggalimbe at cisco.com(...) imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) - Received: anders.gavler at acreo.se (http://www.ietf.org/mail-archive/web/ccamp/current/msg15090.html), jonas.martensson at acreo.se(http://www.ietf.org/mail-archive/web/ccamp/current/msg15094.html) gregb at grotto-networking.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15109.html) |
2013-07-19 |
20 | Daniele Ceccarelli | Annotation tag Other - see Comment Log set. |
2013-03-15 |
20 | Daniele Ceccarelli | Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com( ... Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15010.html), pierre.peloso at alcatel-lucent.com(...) cyril.margaria at nsn.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15014.html) giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15001.html) ggalimbe at cisco.com(...) lyong at ciena.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15015.html) daniele.ceccarelli at ericsson.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14998.html) gregb at grotto-networking.com(...) leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html) danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html), imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) |
2013-03-15 |
20 | Daniele Ceccarelli | Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com( ... Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15010.html), pierre.peloso at alcatel-lucent.com(...) cyril.margaria at nsn.com(...) giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15001.html) ggalimbe at cisco.com(...) lyong at ciena.com(...) daniele.ceccarelli at ericsson.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14998.html) gregb at grotto-networking.com(...) leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html) danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html), imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) |
2013-03-15 |
20 | Daniele Ceccarelli | Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (...) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com(...), pierre.peloso at ... Prepration for WG last call. IPR declariations. diego.caviglia at ericsson.com (...) anders.gavler at acreo.se (...), jonas.martensson at acreo.se(...), i-nishioka at cb.jp.nec.com(...), pierre.peloso at alcatel-lucent.com(...) cyril.margaria at nsn.com(...) giomarti at cisco.com(...) ggalimbe at cisco.com(...) lyong at ciena.com(...) daniele.ceccarelli at ericsson.com(...) gregb at grotto-networking.com(...) leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html) danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html), imajuku.wataru at lab.ntt.co.jp(...) hanjianrui at huawei.com(...) |
2013-03-15 |
20 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-20.txt |
2012-11-08 |
19 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-19.txt |
2012-09-28 |
18 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-18.txt |
2012-09-05 |
17 | Greg Bernstein | New version available: draft-ietf-ccamp-rwa-wson-encode-17.txt |
2012-08-16 |
16 | Greg Bernstein | New version available: draft-ietf-ccamp-rwa-wson-encode-16.txt |
2012-08-08 |
15 | Greg Bernstein | New version available: draft-ietf-ccamp-rwa-wson-encode-15.txt |
2012-04-24 |
14 | Young Lee | New version available: draft-ietf-ccamp-rwa-wson-encode-14.txt |
2011-10-31 |
13 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-13.txt |
2011-08-08 |
12 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-12.txt |
2011-03-14 |
11 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-11.txt |
2011-03-11 |
10 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-10.txt |
2011-03-08 |
09 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-09.txt |
2011-03-01 |
08 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-08.txt |
2010-12-01 |
07 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-07.txt |
2010-10-13 |
06 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-06.txt |
2010-07-12 |
05 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-05.txt |
2010-02-18 |
04 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-04.txt |
2009-10-08 |
03 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-03.txt |
2009-07-10 |
02 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-02.txt |
2009-03-03 |
01 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-01.txt |
2008-12-18 |
00 | (System) | New version available: draft-ietf-ccamp-rwa-wson-encode-00.txt |