idnits 2.17.1 draft-beeram-ccamp-melg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3930 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'B' is mentioned on line 156, but not defined == Missing Reference: 'E' is mentioned on line 156, but not defined == Missing Reference: 'J' is mentioned on line 156, but not defined == Missing Reference: 'C' is mentioned on line 156, but not defined == Missing Reference: 'A' is mentioned on line 162, but not defined == Missing Reference: 'F' is mentioned on line 162, but not defined == Missing Reference: 'I' is mentioned on line 162, but not defined == Missing Reference: 'D' is mentioned on line 162, but not defined Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Vishnu Pavan Beeram (Ed) 3 Internet Draft Juniper Networks 4 Intended status: Standards Track Igor Bryskin (Ed) 5 ADVA Optical Networking 7 Expires: January 15, 2013 July 15, 2013 9 Mutually Exclusive Link Group (MELG) 10 draft-beeram-ccamp-melg-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 15, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document introduces the concept of MELG ("Mutually Exclusive 53 Link Group") and discusses its usage in the context of mutually 54 exclusive Virtual TE Links. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [RFC2119]. 62 Table of Contents 64 1. Introduction...................................................2 65 2. Mutually Exclusive Virtual TE Links............................3 66 3. Mutually Exclusive Link Group..................................6 67 4. Protocol Extensions............................................6 68 4.1. OSPF......................................................6 69 4.2. ISIS......................................................7 70 5. Security Considerations........................................9 71 6. IANA Considerations............................................9 72 6.1. OSPF......................................................9 73 6.2. ISIS......................................................9 74 7. Normative References...........................................9 75 8. Acknowledgments................................................9 77 1. Introduction 79 A Virtual TE Link (as defined in [RFC6001]) advertised into a Client 80 Network Domain represents a potentiality to setup an LSP in the 81 Server Network Domain to support the advertised TE link. The Virtual 82 TE Link gets advertised like any other TE link and follows exactly 83 the same rules that are defined for the advertising, processing and 84 use of regular TE links [RFC4202]. However, "mutual exclusivity" is 85 one attribute that is specific to Virtual TE links. This document 86 discusses the need to advertise this information and the means to do 87 so. 89 2. Mutually Exclusive Virtual TE Links 91 Consider the network topology depicted in Figure 1a. This is a 92 typical packet optical transport deployment scenario where the WDM 93 layer network domain serves as a Server Network Domain providing 94 transport connectivity to the packet layer network Domain (Client 95 Network Domain). 96 | 97 | +---+ /-\ 98 | | | Router ( ) WDM 99 | +---+ Node \-/ node 100 |________________________________ 102 +---+ /-\ /-\ /-\ +---+ 103 | B |-------( E )--------( G )---------( J )---------| C | 104 +---+ \-/ \-/ \-/ +---+ 105 / \ / \ 106 / \ / \ 107 / \ / \ 108 / \ / \ 109 / \ / \ 110 +---+ /-\ /-\ /-\ +---+ 111 | A |---------( F )---------( H )---------( I )---------| D | 112 +---+ \-/ \-/ \-/ +---+ 114 Figure 1a: Sample topology 116 ------------- | [ ] Client TE Node 117 | Client TE | | +++ Client TE Link 118 | DataBase | |_____________________ 119 ------------- 120 [B] ++++++++ [E] [J] +++++++++ [C] 122 [A] ++++++++ [F] [I] +++++++++ [D] 124 Figure 1b: Client TE Database 126 Nodes A, B, C and D are IP routers that are connected to an Optical 127 WDM transport network. E, F, G, H, I and J are WDM nodes that 128 constitute the Server Network Domain. The border nodes (E, F, I and 129 J) operate in both the server and client domains. Figure 1b depicts 130 how the Client Network Domain TE topology looks like when there are 131 no Client TE Links provisioned across the optical domain. 133 | ***** F-J WDM Path (lambda 192000) 134 | @@@@@ E-I WDM Path (lambda 192000) 135 |________________________________ 137 +---+ /-\ @@@@@@@@ /-\ /-\ +---+ 138 | B |-------( E )--------( G )---------( J )---------| C | 139 +---+ \-/ *\-/*@ @*\-/@ +---+ 140 */ \*@ @*/ \@ 141 */ \*@ @*/ \@ 142 */ \*@ @*/ \@ 143 */ \*@*/ \@ 144 */ \*/ \@ 145 +---+ /-\ /-\ /-\ +---+ 146 | A |---------( F )---------( H )---------( I )---------| D | 147 +---+ \-/ \-/ \-/ +---+ 149 Figure 2a: Mutually Exclusive potential WDM paths 151 ------------ | TE-Links E-I and F-J are mutually exclusive 152 | Client-TE| | Advertised with MELG-ID - 25/192000 153 | Database | | [SRLG-ID 25; Shared Resource ID 192000] 154 ------------ |_____________________________________________ 156 [B] ++++++++ [E] [J] +++++++++ [C] 157 ++++ +++++ 158 +++ +++ 159 ++++++ 160 +++ +++ 161 ++++ +++++ 162 [A] ++++++++ [F] [I] +++++++++ [D] 164 Figure 2b: Client TE Database - Mutually Exclusive Virtual TE Links 165 Now consider augmenting the Client TE topology by creating a couple 166 of Virtual TE Links across the optical domain. The potential paths 167 in the WDM network catering to these two virtual TE links are as 168 shown in Fig 2a and the corresponding augmented Client TE topology 169 is as illustrated in Fig 2b. 171 In this particular example, the potential paths in the WDM layer 172 network supporting the Virtual TE Links not only intersect, but also 173 require the usage of the same resource (lambda channel 192000) on 174 the intersection. Because the Virtual TE Links depend on the same 175 uncommitted network resource, only one of them could get activated 176 at any given time. In other words they are mutually exclusive. This 177 scenario is encountered when the potential paths depend on any 178 common physical resource (e.g. transponder, regenerator, wavelength 179 converter, etc.) that could be used by only one Server Network 180 Domain LSP at a time. 182 For a Client Network Domain path computation function (especially a 183 centralized one) that is capable of concurrent computation of 184 multiple paths, it is important to know the existence of mutually 185 exclusive relationship between Virtual TE Links. Absent this 186 information, there exists the risk of yielding erroneous concurrent 187 path computation results where only a subset of the computed paths 188 can get successfully provisioned. This document introduces the 189 concept of Mutually Exclusive Link Group to address this problem. 191 The Virtual TE Link mutual exclusivity attribute can be either (a) 192 Static or (b) Dynamic. 194 In case (a), the Virtual TE Link mutual exclusivity exists 195 permanently within a given network configuration. This type of 196 mutual exclusivity comes into play when two or more Virtual TE Links 197 depend on a Server Network Domain resource that could be used in its 198 entirety by only one Virtual TE Link (when committed). 200 In case (b), the Virtual TE Link mutual exclusivity exists 201 temporarily within a given network configuration. This type of 202 mutual exclusivity comes into play when two or more Virtual TE Links 203 depend on a Server Network Domain resource that could be shared 204 simultaneously in some limited capacity by several Virtual TE Links 205 (when committed). Consider, for example, a situation when three 206 Virtual TE Links depend on a Server Domain WDM link that currently 207 has two lambda channels available. Consider further that each 208 Virtual TE Link (in order to be committed) requires one lambda 209 channel to be allocated on said WDM link. Obviously, under these 210 conditions only two out of three Virtual TE Links could be 211 concurrently committed. Such Virtual TE Link mutual exclusivity is 212 dynamic and temporary because as soon as additional lambda channels 213 become available on the WDM link, the Virtual TE Link mutual 214 exclusivity will cease to exist - it will become possible to commit 215 all three Virtual TE Links concurrently. 217 This revision of the draft discusses only the Static Virtual TE Link 218 mutual exclusivity. Dynamic Virtual TE Link mutual exclusivity will 219 be addressed in later revisions. 221 3. Mutually Exclusive Link Group 223 The Mutually Exclusive Link Group (MELG) construct defined in this 224 document has 2 purposes 226 - To indicate via a separate network unique number (MELG ID) an 227 element or a situation that makes the advertised Virtual TE Link 228 belong to one or more Mutually Exclusive Link Groups. Path 229 computing element will be able to decide on whether two or more 230 Virtual TE Links are mutually exclusive or not by finding an 231 overlap of advertised MELGs (similar to deciding on whether two or 232 more TE links share fate or not by finding common SRLGs) 234 - To indicate whether the advertised Virtual TE Link is committed or 235 not at the moment of the advertising. Such information is 236 important for a path computation element: Committing new Virtual 237 TE links (vs. re-using already committed ones) has a consequence 238 of allocating more server layer resources and disabling other 239 Virtual TE Links that have common MELGs with newly committed 240 Virtual TE Links; Committing a new Virtual TE Link also means a 241 longer setup time for the Client LSP and higher risk of setup- 242 failure. 244 4. Protocol Extensions 245 4.1. OSPF 247 The MELG is a sub-TLV of the top level TE Link TLV. It may occur at 248 most once within the Link TLV. The format of the MELGs sub-TLV is 249 defined as follows: 251 Name: MELG 252 Type: TBD 253 Length: Variable 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Sub-TLV Type | Sub-TLV Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | VTE-Flags (16 bits) |U | Number of MELGs (16 bits) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | MELGID1 (64 bits) | 262 | MELGID2 (64 bits) | 263 | ........................ | 264 | MELGIDn (64 bits) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Number of MELGs: number of MELGS advertised for the 268 Virtual TE Link; 269 VTE-Flags: Virtual TE Link specific flags; 270 MELGID1,MELGID2,...,MELGIDn: 64-bit network domain unique numbers 271 associated with each of the advertised 272 MELGs 273 Currently defined Virtual TE Link specific flags are: 274 U bit (bit 1): Uncommitted - if set, the Virtual TE Link is 275 uncommitted at the time of the advertising (i.e. the server layer 276 network LSP is not set up); if cleared, the Virtual TE Link is 277 committed (i.e. the server layer LSP is fully provisioned and 278 functioning). All other bits of the "VTE-Flags" field are 279 reserved for future use and MUST be cleared. 281 Note: A Virtual TE Link advertisement MAY include MELGs sub-TLV with 282 zero MELGs for the purpose of communicating to the TE domain whether 283 the Virtual TE Link is currently committed or not. 285 4.2. ISIS 287 The MELG TLV (of type TBD) contains a data structure consisting of: 289 6 octets of System ID 290 1 octet of Pseudonode Number 291 1 octet Flag 292 4 octets of IPv4 interface address or 4 octets of a Link 293 Local Identifier 294 4 octets of IPv4 neighbor address or 4 octets of a Link 295 Remote Identifier 296 2 octets MELG-Flags 297 2 octets - Number of MELGs 298 variable List of MELG values, where each element in the list 299 has 8 octets 301 The following illustrates encoding of the value field of the MELG 302 TLV. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | System ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | System ID (cont.) |Pseudonode num | Flags | 310 +-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 311 | Ipv4 interface address/Link Local Identifier | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Ipv4 neighbor address/Link Remote Identifier | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | VTE-Flags (16 bits) |U | Number of MELGs (16 bits) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | MELGID1 (64 bits) | 318 | MELGID2 (64 bits) | 319 | ........................ | 320 | MELGIDn (64 bits) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The neighbor is identified by its System ID (6 octets), plus one octet 324 to indicate the pseudonode number if the neighbor is on a LAN 325 interface. 327 The least significant bit of the Flag octet indicates whether the 328 interface is numbered (set to 1) or unnumbered (set to 0). All other 329 bits are reserved and should be set to 0. 331 The length of the TLV is 20 + 8 * (number of MELG values). 333 The semantics of "VTE-Flags", "Number of MELGs" and "MELGID Values" are 334 the same as the ones defined under OSPF extensions. 336 The MELG TLV MAY occur more than once within the IS-IS Link State 337 Protocol Data Units. 339 5. Security Considerations 341 TBD 343 6. IANA Considerations 345 6.1. OSPF 347 IANA is requested to allocate a new sub-TLV type for MELG (as 348 defined in Section 4.1) under the top-level TE Link TLV. 350 6.2. ISIS 352 IANA is requested to allocate a new IS-IS TLV type for MELG (as 353 defined in Section 4.2). 355 7. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC4202] K.Kompella, Y.Rekhter, "Routing Extensions in Support 361 of Generalized Multi-Protocol Label Switching (GMPLS)", 362 RFC4202, October 2005. 364 [RFC6001] D.Papadimitriou, M.Vigoureax, K.Shiomoto, D.Brungard 365 and JL. Le Roux, "GMPLS Protocol Extensions for Multi- 366 Layer and Multi-Region Networks", RFC 6001, October 367 2010. 369 8. Acknowledgments 371 Chris Bowers [cbowers@juniper.net] 373 Authors' Addresses 375 Vishnu Pavan Beeram 376 Juniper Networks 377 Email: vbeeram@juniper.net 379 Igor Bryskin 380 ADVA Optical Networking 381 Email: ibryskin@advaoptical.com 382 John Drake 383 Juniper Networks 384 Email: jdrake@juniper.net 386 Gert Grammel 387 Juniper Networks 388 Email: ggrammel@juniper.net 390 Wes Doonan 391 ADVA Optical Networking 392 Email: wdoonan@advaoptical.com 394 Manuel Paul 395 Deutsche Telekom 396 Email: Manuel.Paul@telekom.de 398 Ruediger Kunze 399 Deutsche Telekom 400 Email: Ruediger.Kunze@telekom.de 402 Oscar Gonzalez de Dios 403 Telefonica 404 Email: ogondio@tid.es 406 Cyril Margaria 407 Coriant GmbH 408 Email: cyril.margaria@coriant.com 410 Friedrich Armbruster 411 Coriant GmbH 412 Email: friedrich.armbruster@coriant.com 414 Daniele Ceccarelli 415 Ericsson 416 Email: daniele.ceccarelli@ericsson.com