Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)
draft-ietf-ccamp-gmpls-ason-routing-reqts-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
2005-03-30
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-03-23
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-03-23
|
05 | Amy Vezza | IESG has approved the document |
2005-03-23
|
05 | Amy Vezza | Closed "Approve" ballot |
2005-02-09
|
05 | Alex Zinin | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Alex Zinin |
2005-01-28
|
05 | Alex Zinin | checking with WG chairs if we can respin this doc with a NULL IANA section |
2004-12-15
|
05 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
2004-10-29
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-10-29
|
05 | (System) | Removed from agenda for telechat - 2004-10-28 |
2004-10-28
|
05 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2004-10-28
|
05 | Bill Fenner | [Ballot discuss] Placeholder for liaison issues |
2004-10-28
|
05 | Bill Fenner | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner |
2004-10-28
|
05 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-10-28
|
05 | Michelle Cotton | IANA Comments: Section 4.5.3 and 4.5.4 have some defined values. Does IANA need to do anything with these? |
2004-10-28
|
05 | Harald Alvestrand | [Ballot comment] Reviewed by Michael Patton, Gen-ART Review entered as comment on document. A number of typos that may warrant another spin, but not blocking. |
2004-10-28
|
05 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-10-28
|
05 | Harald Alvestrand | Review by Michael Patton, Gen-ART Summary: This draft is ready for publication as an Informational RFC I managed to comprehend the whole document, in isolation. … Review by Michael Patton, Gen-ART Summary: This draft is ready for publication as an Informational RFC I managed to comprehend the whole document, in isolation. But, without an understanding of the several ITU references, none of which I've read, I can't comment on whether it is really a good set of requirement definitions. General comment: There's a bit of cognitive disonance in the terminology because of the meshing of circuit switching and packet switching in the descriptions. I don't think this is enough to slow the document. If the document does go through another round, I might be persuaded to catalog some of them. However, once I realized that I needed to do a TPC to TCP mapping of terminology, it all became clear. In sections 4.5.1 and 4.5.4 the term SRLG appears, but is never expanded or explained. While it may be explained in one of the references, at least expanding it at first use would be nice. Neither of the references is important enough to make this a restrictive problem, but it would be nice to have an expansion. typos ----- Section 3 "provides among other capabilities support" => "provides, among other capabilities, support" bottom of pages 5 and 13 have orphaned section headings. Section 4.2 "SHOULD not" => "SHOULD NOT" Section 4.2 the last sentence of paragraph 3 ("This MAY be achieved using a number of mechanisms.") doesn't really say anything. It's the way you lead into a list of the said mechanisms, but there isn't a list, so that construct is meaningless. I think what they meant was "This specification does not restrict the mechanisms by which this may be achieved." Section 4.5.4 under "Connection Types" shouldn't the abbreviation for "Termination Connection Point" be TCP (a confusing one, I must admit, but not as confusing as having them both be the same)? It certinly seems to be referenced this way at other points in the document. And later that assumption is verified by the Terminology section. One typo seems to be systematic, the word "bounded" is used where "bound" is obviously meant. Interestingly enough there are a few places where the words are used correctly. These are the erroneous uses that I found: Section 4 "at each RC bounded to the same RA" => "at each RC bound to the same RA" Section 4.2 "RC(s) bounded to a RA" => "RC(s) bound to a RA" Section 4.5.2 "the advertisement is bounded" => "the advertisement is bound" Section 6 "RCs bounded to different" => "RCs bound to different" and the related one: Section 6 "when multiple RCs bound to a single RA" should either be "when multiple RCs are bound to a single RA" or"when multiple RCs bind to a single RA" I think the first of those two is more correct. |
2004-10-27
|
05 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-10-27
|
05 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-10-26
|
05 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2004-10-26
|
05 | Steven Bellovin | [Ballot comment] Should the security considerations section reference the rpsec work? |
2004-10-26
|
05 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-10-25
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2004-10-25
|
05 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck |
2004-10-25
|
05 | Scott Hollenbeck | [Ballot comment] Missing IANA Considerations. |
2004-10-25
|
05 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-10-21
|
05 | Alex Zinin | State Changes to IESG Evaluation from AD Evaluation::AD Followup by Alex Zinin |
2004-10-21
|
05 | Alex Zinin | Placed on agenda for telechat - 2004-10-28 by Alex Zinin |
2004-10-21
|
05 | Alex Zinin | [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin |
2004-10-21
|
05 | Alex Zinin | Ballot has been issued by Alex Zinin |
2004-10-21
|
05 | Alex Zinin | Created "Approve" ballot |
2004-10-21
|
05 | (System) | Ballot writeup text was added |
2004-10-21
|
05 | (System) | Last call text was added |
2004-10-21
|
05 | (System) | Ballot approval text was added |
2004-10-13
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-10-13
|
05 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt |
2004-06-04
|
05 | Alex Zinin | State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Alex Zinin |
2004-06-04
|
05 | Alex Zinin | AD-review comments: The list of authors is too long according to the recent RFC Editor policies. Same comment regarding the 2119 languages as for the … AD-review comments: The list of authors is too long according to the recent RFC Editor policies. Same comment regarding the 2119 languages as for the previous document. Comments on specific parts of the text: > 4. ASON Routing Architecture and Requirements ... > The failure of a RC, or the failure of communications between RCs, > and the subsequent recovery from the failure condition MUST NOT > disrupt calls in progress and their associated connections. Calls ^^^^^^^^^^^^^^^^^ it took a while to realize that what's meant here wasn't calls in the process of being established, but those already established. Some wording changes might help here. > 4.2 Hierarchical Routing Information Dissemination ... > If routing information is > exchanged between a RC, its parent, and its child RCs, it SHOULD > include reachability and MAY include (upon policy decision) node and > link topology. Communication between RAs only takes place between > RCs with a parent/child relationship. the definition of "reachability" has been given at this point and the reader wonders what it is. > Multiple RCs bound to the same RA MAY transform (filter, summarize, > etc.) and then forward information to RCs at different levels. > However in this case the resulting information at the receiving > level must be self-consistent; this MAY be achieved using a number > of mechanisms. it would be useful to explain what "self-consistent" means in this context. > 3. Method of Communication > > Two approaches exist for communication between Level N and N+1. > > - The first approach places an instance of a Level N routing > function and an instance of a Level N+1 routing function in the > same system. The communications interface is within a single > system and is thus not an open interface subject to > standardization. This is right in a sense that one doesn't have to define how to _take_ info level N for later announcement to N+1. However, certain aspects of such reannouncement or leaking will have to be done in a consistent manner to ensure interoperability and basic protocol correctness (e.g., cost/metric value). > 4.5 Routing Attributes > > Routing for transport networks is performed on a per layer basis, > where the routing paradigms MAY differ among layers and within a > layer. Not all equipment supports the same set of transport layers > or the same degree of connection flexibility at any given layer. A > server layer trail may support various clients, involving different > adaptation functions. Additionally, equipment may support variable > adaptation functionality, whereby a single server layer trail > dynamically supports different multiplexing structures. As a result, > routing information MAY include layer specific, layer independent, > and client/server adaptation information. The notions of "server", "layer", "server layer trail", "client", etc. haven't been defined and are completely foreign for a usual IETF reader. > 4.5.3 Node Attributes > > All nodes belong to a RA, hence, the RA ID can be considered an > attribute of all nodes. Given that no distinction is made between > abstract nodes and those that cannot be decomposed any further, the > same attributes MAY be used for their advertisement. In the > following tables, Capability refers to the level of support required > in the realization of a link state routing protocol, whereas Usage > refers to the degree of operational and implementation flexibility. The last sentence doesn't really help understanding what "Usage" below is used for from the protocol design perspective. Please clarify. > > The following Node Attributes are defined: > > Attribute Capability Usage > ----------- ----------- --------- > 4.5.4 Link Attributes > > The following Link Attributes are defined: > > Link Attribute Capability Usage > --------------- ----------- --------- > Local SNPP link ID REQUIRED REQUIRED > Remote SNPP link ID REQUIRED REQUIRED > Layer Specific Characteristics see Table 3 > > Table 2. Link Attributes > > The SNPP link ID MUST be sufficient to uniquely identify the > corresponding transport plane resource taking into account Is it in conjunction with the Node ID? > 5. Security Considerations > > ASON routing protocol MUST deliver the operational security > objectives where required. What are they? > These objectives do not necessarily imply > requirements on the routing protocol itself, and MAY be met by other > established means. Same comment about the ITU-T references as for the previous document. |
2004-05-11
|
05 | Alex Zinin | Draft Added by Alex Zinin |
2004-05-05
|
04 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt |
2004-04-09
|
03 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt |
2004-02-03
|
02 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt |
2003-12-23
|
01 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt |
2003-12-02
|
00 | (System) | New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-00.txt |