idnits 2.17.1 draft-ietf-ccamp-ospf-gmpls-extensions-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([GMPLS-ROUTING]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 249: '... restarting node SHOULD originate the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-06 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-01 == Outdated reference: A later version (-08) exists of draft-ietf-ospf-hitless-restart-02 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group K. Kompella (Juniper Networks) 3 Internet Draft Y. Rekhter (Juniper Networks) 4 Expiration Date: October 2002 A. Banerjee (Calient Networks) 5 J. Drake (Calient Networks) 6 G. Bernstein (Ciena) 7 D. Fedyk (Nortel Networks) 8 E. Mannie (GTS Network) 9 D. Saha (Tellium) 10 V. Sharma (Metanoia, Inc.) 12 OSPF Extensions in Support of Generalized MPLS 14 draft-ietf-ccamp-ospf-gmpls-extensions-05.txt 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 2. Abstract 39 This document specifies encoding of extensions to the OSPF routing 40 protocol in support of Generalized Multi-Protocol Label Switching 41 (GMPLS). The description of the extensions is specified in [GMPLS- 42 ROUTING]. 44 3. Summary for Sub-IP Area 46 3.1. Summary 48 This document specifies encoding of extensions to the OSPF routing 49 protocol in support of Generalized Multi-Protocol Label Switching 50 (GMPLS). The description of the extensions is specified in [GMPLS- 51 ROUTING]. 53 3.2. Where does it fit in the Picture of the Sub-IP Work 55 This work fits squarely in either the CCAMP or OSPF box. 57 3.3. Why is it Targeted at this WG 59 This draft is targeted at the CCAMP or the OSPF WG, because this 60 draft specifies the extensions to the OSPF routing protocols in 61 support of GMPLS, because GMPLS is within the scope of the CCAMP WG, 62 and because OSPF is within the scope of the OSPF WG. 64 3.4. Justification 66 The WG should consider this document as it specifies the extensions 67 to the OSPF routing protocols in support of GMPLS. 69 4. Introduction 71 This document specifies extensions to the OSPF routing protocol in 72 support of carrying link state information for Generalized Multi- 73 Protocol Label Switching (GMPLS). The set of required enhancements to 74 OSPF are outlined in [GMPLS-ROUTING]. 76 5. OSPF Routing Enhancements 78 In this section we define the enhancements to the TE properties of 79 GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic 80 Engineering (TE) LSA, which is an opaque LSA with area flooding scope 81 [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and 82 has one or more nested sub-TLVs for extensibility. The top-level TLV 83 can take one of two values (1) Router Address or (2) Link. In this 84 document, we enhance the sub-TLVs for the Link TLV in support of 85 GMPLS. Specifically, we add the following sub-TLVs to the Link TLV: 87 1. Link Local Identifier, 88 2. Link Remote Identifier, 89 3. Link Protection Type, 90 4. Interface Switching Capability Descriptor, and 91 5. Shared Risk Link Group. 93 The following defines the Type and Length of these sub-TLVs: 95 Sub-TLV Type Length Name 96 11 4 Link Local Identifier 97 12 4 Link Remote Identifier 98 14 4 Link Protection Type 99 15 variable Interface Switching Capability Descriptor 100 16 variable Shared Risk Link Group 102 5.1. Link Local Identifier 104 A Link Local Identifier is a sub-TLV of the Link TLV with type 11, 105 and length 4. 107 5.2. Link Remote Identifier 109 A Link Remote Identifier is a sub-TLV of the Link TLV with type 12, 110 and length 4. 112 5.3. Link Protection Type 114 The Link Protection Type is a sub-TLV of the Link TLV, with type 14, 115 and length of four octets, the first of which is a bit vector 116 describing the protection capabilities of the link. They are: 118 0x01 Extra Traffic 120 0x02 Unprotected 122 0x04 Shared 124 0x08 Dedicated 1:1 126 0x10 Dedicated 1+1 128 0x20 Enhanced 130 0x40 Reserved 132 0x80 Reserved 134 5.4. Shared Risk Link Group (SRLG) 136 The SRLG is a sub-TLV of the Link TLV with type 16. The length is the 137 length of the list in octets. The value is an unordered list of 32 138 bit numbers that are the SRLGs that the link belongs to. The format 139 of the value field is as shown below: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Shared Risk Link Group Value | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | ............ | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Shared Risk Link Group Value | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 5.5. Interface Switching Capability Descriptor 152 The Interface Switching Capability Descriptor is a sub-TLV of the 153 Link TLV with type 15. The length is the length of value field in 154 octets. The format of the value field is as shown below: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Switching Cap | Encoding | Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Max LSP Bandwidth at priority 0 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Max LSP Bandwidth at priority 1 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Max LSP Bandwidth at priority 2 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Max LSP Bandwidth at priority 3 | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Max LSP Bandwidth at priority 4 | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Max LSP Bandwidth at priority 5 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Max LSP Bandwidth at priority 6 | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Max LSP Bandwidth at priority 7 | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Switching Capability-specific information | 178 | (variable) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 The Switching Capability (Switching Cap) field contains one of the 182 following values: 184 1 Packet-Switch Capable-1 (PSC-1) 185 2 Packet-Switch Capable-2 (PSC-2) 186 3 Packet-Switch Capable-3 (PSC-3) 187 4 Packet-Switch Capable-4 (PSC-4) 188 51 Layer-2 Switch Capable (L2SC) 189 100 Time-Division-Multiplex Capable (TDM) 190 150 Lambda-Switch Capable (LSC) 191 200 Fiber-Switch Capable (FSC) 193 The Encoding field contains one of the values specified in Section 194 3.1.1 of [GMPLS-SIG]. 196 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 197 the IEEE floating point format, with priority 0 first and priority 7 198 last. The units are bytes (not bits!) per second. 200 The content of the Switching Capability specific information field 201 depends on the value of the Switching Capability field. 203 When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 204 the specific information includes Interface MTU, Minimum LSP 205 Bandwidth, and padding. The Interface MTU is encoded as a 2 octets 206 integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field 207 in the IEEE floating point format. The units are bytes (not bits!) 208 per second. The padding is 2 octets, and is used to make the 209 Interface Switching Capability Descriptor sub-TLV 32-bits aligned. 211 When the Switching Capability field is L2SC, there is no specific 212 information. 214 When the Switching Capability field is TDM, the specific information 215 includes Minimum LSP Bandwidth, an indication whether the interface 216 supports Standard or Arbitrary SONET/SDH, and padding. The Minimum 217 LSP Bandwidth is encoded in a 4 octets field in the IEEE floating 218 point format. The units are bytes (not bits!) per second. The 219 indication whether the interface supports Standard or Arbitrary 220 SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the 221 interface supports Standard SONET/SDH, and 1 if the interface 222 supports Arbitrary SONET/SDH. The padding is 3 octets, and is used 223 to make the Interface Switching Capability Descriptor sub-TLV 32-bits 224 aligned. 226 When the Switching Capability field is LSC, there is no specific 227 information. 229 The Interface Switching Capability Descriptor sub-TLV may occur more 230 than once within the Link TLV. 232 6. Implications on Graceful Restart 234 The restarting node should follow the OSPF restart procedures [OSPF- 235 RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP]. 237 When a restarting node is going to originate its TE LSAs, the TE LSAs 238 containing Link TLV should be originated with 0 unreserved bandwidth, 239 and if the Link has LSC or FSC as its Switching Capability then also 240 with 0 as Max LSP Bandwidth, until the node is able to determine the 241 amount of unreserved resources taking into account the resources 242 reserved by the already established LSPs that have been preserved 243 across the restart. Once the restarting node determines the amount of 244 unreserved resources, taking into account the resources reserved by 245 the already established LSPs that have been preserved across the 246 restart, the node should advertise these resources in its TE LSAs. 248 In addition in the case of a planned restart prior to restarting, the 249 restarting node SHOULD originate the TE LSAs containing Link TLV with 250 0 as unreserved bandwidth, and if the Link has LSC or FSC as its 251 Switching Capability then also with 0 as Max LSP Bandwidth. 253 Neighbors of the restarting node should continue advertise the actual 254 unreserved bandwidth on the TE links from the neighbors to that node. 256 Regular graceful restart should not be aborted if a TE LSA or TE 257 topology changes. TE graceful restart need not be aborted if a TE LSA 258 or TE topology changes. 260 7. Security Considerations 262 The sub-TLVs proposed in this document does not raise any new 263 security concerns. 265 8. Acknowledgements 267 The authors would like to thank Suresh Katukam, Jonathan Lang and 268 Quaizar Vohra for their comments on the draft. 270 9. References 272 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 273 OSPF", 274 draft-katz-yeung-ospf-traffic-06.txt (work in progress) 276 [GMPLS-SIG] "Generalized MPLS - Signaling Functional 277 Description", draft-ietf-mpls-generalized-signaling-04.txt (work 278 in progress) 280 [GMPLS-RSVP] "Generalized MPLS Signaling - RSVP-TE Extensions", 281 draft-ietf-mpls-generalized-rsvp-te-06.txt (work in progress) 283 [GMPLS-ROUTING] "Routing Extensions in Support of Generalized MPLS", 284 draft-ietf-ccamp-gmpls-routing-01.txt (work in progress) 286 [OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless- 287 restart-02.txt 288 (work in progress) 290 10. Authors' Information 292 Kireeti Kompella 293 Juniper Networks, Inc. 294 1194 N. Mathilda Ave 295 Sunnyvale, CA 94089 296 Email: kireeti@juniper.net 298 Yakov Rekhter 299 Juniper Networks, Inc. 300 1194 N. Mathilda Ave 301 Sunnyvale, CA 94089 302 Email: yakov@juniper.net 303 Ayan Banerjee 304 Calient Networks 305 5853 Rue Ferrari 306 San Jose, CA 95138 307 Phone: +1.408.972.3645 308 Email: abanerjee@calient.net 310 John Drake 311 Calient Networks 312 5853 Rue Ferrari 313 San Jose, CA 95138 314 Phone: (408) 972-3720 315 Email: jdrake@calient.net 317 Greg Bernstein 318 Ciena Corporation 319 10480 Ridgeview Court 320 Cupertino, CA 94014 321 Phone: (408) 366-4713 322 Email: greg@ciena.com 324 Don Fedyk 325 Nortel Networks Corp. 326 600 Technology Park Drive 327 Billerica, MA 01821 328 Phone: +1-978-288-4506 329 Email: dwfedyk@nortelnetworks.com 331 Eric Mannie 332 GTS Network Services 333 RDI Department, Core Network Technology Group 334 Terhulpsesteenweg, 6A 335 1560 Hoeilaart, Belgium 336 Phone: +32-2-658.56.52 337 E-mail: eric.mannie@gtsgroup.com 338 Debanjan Saha 339 Tellium Optical Systems 340 2 Crescent Place 341 P.O. Box 901 342 Ocean Port, NJ 07757 343 Phone: (732) 923-4264 344 Email: dsaha@tellium.com 346 Vishal Sharma 347 Metanoia, Inc. 348 335 Elan Village Lane, Unit 203 349 San Jose, CA 95134-2539 350 Phone: +1 408-943-1794 351 Email: v.sharma@ieee.org