Document: draft-ietf-tewg-diff-te-mam-03.txt draft-ietf-tewg-diff-te-mar-04.txt draft-ietf-tewg-diff-te-proto-07.txt draft-ietf-tewg-diff-te-russian-06.txt Reviewer: Lucy E. Lynch Date: 18 augusti 2004 All - When I looked at this docket in April I said: "These four documents have nested dependencies on work in progress: [ISIS-TE] <- [DSTE-PROTO] <-[DSTE-MAM] <-[DSTE-MAR] <-[DSTE-RDM] There is a normative ref to [ISIS-TE] in [DSTE-PROTO] and the other three all have normative refs to [DSTE-PROTO] which also contains significant IANA considerations." ISIS-TE is now approved, and I've reviewed this docket again: One of these (draft-ietf-tewg-diff-te-mar-04.txt) carries the Experimental tag, the other 3 don't say... given the level of complexity here, I'd go with a "No Real Objection" to all 4 AS experimental. ^^ I'll note that recent mailing list traffic raised questions about intra vs inter-domain scalablity of configuration as well as the possible need for a recommendation for "standard mapping" of the 8x8 Classtype/ preemption priority matrix. I also would express some concerns about mixing and matching among the three constraint models. (MAR/MAM/RDM) If the inter-domain questions persist and the Path Computation Element work takes off, this whole area might need an architecture review as many of these extensions feel "bolted on" to existing work. (2 cents) --------------------------------------------------------------------- Details: [PROTO] Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering draft-ietf-tewg-diff-te-proto-07.txt ------------------------------------- idnits 1.34 (28 Jul 2004) draft-ietf-tewg-diff-te-proto-07.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. There are 1 instances of too long lines in the document, -- the longest one being 2 characters in excess of 72. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer There are 32 instances of lines with hyphenated line breaks in the document. Line 391 has weird spacing: '...hat LSP must ...' Line 1008 has weird spacing: '... Value Err...' Line 1388 has weird spacing: '... Value Err...' MY NITS Numbering Glitch - section 4: http://ops.ietf.org/lists/te-wg/te-wg.2004/msg00142.html "Hm... Yes, we have a little numbering glitch in diff-te-proto-07. But the authors of interas-mpls-te-req-07 had read it right: section 4.1.1 should be numbered 4.1. Specifically: "4.1.1. Link Parameters" should read "4.1. Link Parameters" "4.1.2. Bandwidth Constraints (BCs)" should read "4.1.1. Bandwidth Constraints (BCs)" "4.1.3. Overbooking" should read "4.1.2. Overbooking" So again, the reference in interas-mpls-te-req-07 is correct and should be kept as is, and we will correct diff-te-proto. Thanks Francois" 4.2.1. TE-Class Mapping "DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the Class-Type and preemption level are configured for each of (up to) 8 TE-Classes. This mapping is referred to as : TE-Class[i] <--> < CTc , preemption p > Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 Two TE-Classes must not be identical (i.e. have both the same Class- ^^^^^^^^ Type and the same preemption priority)." - is this a MUST NOT ??? 6.2.1. CLASSTYPE object "Class Number = TBD Class Type = 1 To be removed by the RFC editor at the time of publication: When the RSVP Class Number is assigned by IANA replace "TBD" above by the assigned value. See IANA Considerations section for allocation request. 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 | CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 29 bits This field is reserved. It must be set to zero on transmission ^^^^ and must be ignored on receipt." ^^^^ - Should these both be MUST ??? IANA Related Question - The Proto document has a number of new IANA related considerations which are nested within the ISIS and OSPF extensions - has someone with a better handle on IANA admin issues taken a look at this? (see below) [MAM] Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering draft-ietf-tewg-diff-te-mam-03.txt ----------------------------------------- idnits 1.34 (28 Jul 2004) draft-ietf-tewg-diff-te-mam-02.txt: The document seems to lack an Authors' Addresses Section Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. There are 12 instances of too long lines in the document, -- the longest one being 7 characters in excess of 72. There are 34 instances of lines with non-ascii characters in the document. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer There are 6 instances of lines with hyphenated line breaks in the document. Note - The preemption table and ascii art in section 3 is really useful - something similar in PROTO would be nice (8x8 matrix) [MAR] Max Allocation with Reservation Bandwidth Constraints Model for DiffServ-aware MPLS Traffic Engineering & Performance Comparisons ----------------------------------------------------------------- idnits 1.34 (28 Jul 2004) draft-ietf-tewg-diff-te-mar-03.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? There are 11 instances of too long lines in the document, -- the longest one being 4 characters in excess of 72. There are 36 instances of lines with control characters in the document. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure Invitation Line 916 has weird spacing: '...cedures for...' Comments - This document is very readable, and steps/branches/etc. are clearly defined. Language Question: 1. Introduction "This document is intended to complement the DS-TE requirements document [DSTE-REQ] by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model." - "is intended to be" ??? [RDB] Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering draft-ietf-tewg-diff-te-russian-06.txt ---------------------------------------- idnits 1.34 (28 Jul 2004) draft-ietf-tewg-diff-te-russian-06.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. There are 2 instances of too long lines in the document, -- the longest one being 2 characters in excess of 72. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure Invitation There are 6 instances of lines with hyphenated line breaks in the document. Comments - The model is well defined here, but I'm not clear how this would/wouldn't interact with MAR/MAM extra info below ______________________________________________________________________________ PROTO IANA Backgound: [PROTO] "14. IANA Considerations This document creates two new name spaces which are to be managed by IANA. Also, a number of assignments from existing name spaces have been made by IANA in this document. Those are discussed below. 14.1. A new name space for Bandwidth Constraints Model Identifiers This document defines in section 5.1 a "Bandwidth Constraints Model Id" field (name space) within the "Bandwidth Constraints" sub-TLV, both for OSPF and ISIS. IANA is requested to create and maintain this new name space. The field for this namespace is 1 octet, and IANA guidelines for assignments for this field are as follows: o values in the range 0-127 are to be assigned according to the "Specification Required" policy defined in [IANA-CONS]. o values in the range 128-239 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that cover assignment within that range. o values in the range 240-255 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs. 14.2. A new name space for Error Values under the "Diff-Serv-aware TE Error" An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to broadly define an error condition. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error. This document defines in section 6.5 a new RSVP error code, the "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for the "Diff-Serv-aware TE Error" constitute a new name space to be managed by IANA. This document defines, in section 6.5, values 1 through 7 in that name space (see section 14.3.5). Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA- CONS]. 14.3. Assignments made in this Document 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 [OSPF-TE] creates a name space for the sub-TLV types within the "Link TLV" of the Traffic Engineering LSA and rules for management of this name space by IANA. This document defines in section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested and the value TBD has been assigned by IANA for the "Bandwidth Constraints" sub-TLV. To be removed by the RFC editor at the time of publication: When the sub-TLV Type is assigned by IANA replace "TBD" above by the assigned value. 14.3.2. Bandwidth Constraints sub-TLV for ISIS [ISIS-TE] creates a name space for the sub-TLV types within the ISIS "Extended IS Reachability" TLV and rules for management of this name space by IANA. This document defines in section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In accordance with the IANA considerations provided in [ISIS-TE], a sub- TLV type was requested and the value TBD has been assigned by IANA for the "Bandwidth Constraints" sub-TLV. To be removed by the RFC editor at the time of publication: When the sub-TLV Type is assigned by IANA replace "TBD" above by the assigned value. 14.3.3. CLASSTYPE object for RSVP [RSVP] defines the Class Number name space for RSVP object which is managed by IANA. Currently allocated Class Numbers are listed at "http://www.iana.org/assignments/rsvp-parameters" This document defines in section 6.2.1 a new RSVP object, the CLASSTYPE object. IANA was requested to assign a Class Number for this RSVP object from the range defined in section 3.10 of [RSVP] for those objects which, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number (i.e. Class-Num = 0bbbbbbb). IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object. To be removed by the RFC editor at the time of publication: When the RSVP Class-Num is assigned by IANA replace "TBD" above by the assigned value. 14.3.4. "Diff-Serv-aware TE Error" Error Code [RSVP] defines the Error Code name space and rules for management of this name space by IANA. Currently allocated Error Codes are listed at "http://www.iana.org/assignments/rsvp-parameters" This document defines in section 6.5 a new RSVP Error Code, the "Diff-Serv-aware TE Error". In accordance with the IANA considerations provided in [RSVP], Error Code TBD was assigned by IANA to the "Diff-Serv-aware TE Error". To be removed by the RFC editor at the time of publication: When the RSVP Class-Num is assigned by IANA replace "TBD" above by the assigned value. 14.3.5. Error Values for "Diff-Serv-aware TE Error" An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to broadly define an error condition. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error. This document defines in section 6.5 a new RSVP error code, the "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for the "Diff-Serv-aware TE Error" constitute a new name space to be managed by IANA. This document defines, in section 6.5, the following Error Values for the "Diff-Serv-aware TE Error": Value Error 1 Unexpected CLASSTYPE object 2 Unsupported Class-Type 3 Invalid Class-Type value 4 Class-Type and setup priority do not form a configured TE-Class 5 Class-Type and holding priority do not form a configured TE-Class 6 Inconsistency between signaled PSC and signaled Class-Type 7 Inconsistency between signaled PHBs and signaled Class-Type See section 14.2 for allocation of other values in that name space." [ISIS] IS-IS extensions for Traffic Engineering ------------------------------------------------------------------- 6. IANA Considerations 6.1 TLV codepoint allocations This document defines the following new ISIS TLV types that need to be reflected in the ISIS TLV code-point registry: Type Description IIH LSP SNP ---- ----------------------------------- --- --- --- 22 The extended IS reachability TLV n y n 134 The Traffic Engineering router ID TLV n y n 135 The extended IP reachability TLV n y n 6.2 New registries IANA is requested to create the following new registries. This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). Taking into consideration allocations specified in this document, the registry should be initialized as follows: Type Description ---- ----------------------------------- 0-2 unassigned 3 Administrative group (color) 4-5 unassiged 6 IPv4 interface address 7 unassigned 8 IPv4 neighbor address 9 Maximum link bandwidth 10 Reservable link bandwidth 11 Unreserved bandwidth 12-17 unassigned 18 TE Default metric 19-254 unassigned 255 Reserved for future expansion To be removed by the RFC editor at the time of publication At the time of registry creation, please perform the following allocations in this registry: Type Description ---- ----------------------------------- 250 Reserved for Cisco-proprietary extensions 251 Reserved for Cisco-proprietary extensions 6.2.2 Sub-TLVs for TLV 135 This registry contains codepoints for Sub-TLVs of TLV 135. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). No codepoints are defined in this document. [OSPF] Traffic Engineering (TE) Extensions to OSPF Version 2 ----------------------------------------------------------------------- 6. IANA Considerations The top level Types in a TE LSA, as well as Types for sub-TLVs for each top level Type, have been registered with IANA, except as noted. Here are the guidelines (using terms defined in [10]) for the assignment of top level Types in TE LSAs: o Types in the range 3-32767 are to be assigned via Standards Action. o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs. o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.