idnits 2.17.1 draft-dovolsky-ccamp-ospf-limited-flooding-00.txt: -(94): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(240): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(241): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(242): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(286): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(292): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(306): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(307): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(308): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(309): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? ** Missing revision: the document name given in the document, 'draft-dovolsky-ccamp-ospf-limited-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-dovolsky-ccamp-ospf-limited-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-dovolsky-ccamp-ospf-limited-', but the file name used is 'draft-dovolsky-ccamp-ospf-limited-flooding-00' == There are 45 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 407: '...ed flooding type MUST NOT be included;...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 39 has weird spacing: '...osition of a ...' == Line 170 has weird spacing: '...ict the data...' == Line 244 has weird spacing: '...ents in zone...' == Line 271 has weird spacing: '...� may have ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 2002) is 7833 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) -- Looks like a reference, but probably isn't: '---' on line 341 == Unused Reference: '3' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 582, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2370 (ref. '3') (Obsoleted by RFC 5250) -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 8 errors (**), 1 flaw (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Dovolsky (Movaz Networks) 3 I. Bryskin (Movaz Networks) 4 D. Awduche (Isocore) 5 Internet Draft 6 Expiration Date: May 2003 November 2002 7 Document: draft-dovolsky-ccamp-ospf-limited- 8 flooding-00.txt 10 Limited Flooding as a scalability improvement to OSPF 12 draft-dovolsky-ccamp-ospf-limited-flooding-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This draft describes a limited flooding approach to address the 38 problem of routing scalability in link state IGPs. The solution is 39 based on decomposition of a routing area into �zones� and the 40 restriction of the exchange of routing information between zones. 41 This approach introduces an extra level in the isolation of 42 knowledge within a routing domain. The advantage of this solution is 43 that it considerably decreases the amount of information flooded in 44 link state advertisements and reduces the size of the link-state 45 database (and traffic engineering entries) on network elements 46 utilizing link state protocols. The technique presented in this 47 document has been particularized to OSPF in order to make the 48 discussion practical and concrete. However, the underlying concepts 49 are very general and similar modifications can be easily applied to 50 other IGPs, such as ISIS. 52 Table Of Contents 54 Dovolsky, Bryskin, Awduche Expires May 2003 1 55 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 57 1. Summary for Sub-IP Area 59 1.1. Summary 61 This document describes a generic mechanism to enhance the 62 scalability of IGP routing protocols. More particularly, it 63 specifies extensions to the OSPF routing protocol to make the 64 protocol even more scalable in support of Generalized Multi-Protocol 65 Label Switching (GMPLS). The method described is quite general and 66 can be applied to other link state protocols, such as ISIS. 68 1.2. Where does it fit in the Picture of the Sub-IP Work 70 This work fits squarely in either the CCAMP or OSPF box. 72 1.3. Why is it Targeted at this WG 74 This draft is targeted at the CCAMP or the OSPF WG, because it 75 specifies extensions to the OSPF routing protocols in support of 76 GMPLS, because GMPLS is within the scope of the CCAMP WG, and 77 because OSPF is within the scope of the OSPF WG. 79 1.4. Justification 81 The WG should consider this document as it specifies the extensions 82 to the OSPF routing protocols in support of GMPLS. 84 2. Overview 86 This document proposes a method to enhance the scalability of link 87 state interior gateway routing protocols (IGPs). The proposed 88 solution is applicable to traditional link state routing protocols 89 such as OSPF [1]. The proposed solution is even more pertinent in 90 MPLS and GMPLS networks, where the IGP has been extended and 91 equipped with traffic engineering and GMPLS extensions. 93 The main idea behind the proposed approach is the reduction of a 94 single routing area into multiple �zones� and the control of routing 95 information between the zones. With this approach, it is no longer 96 the case that network elements in the same routing area will 97 necessarily have an identical copy of the area link state database. 98 An important attribute of the zone concept is that it requires 99 minimal modifications to the existing IGPs. Another important 100 attribute is that it supports asymmetric exchange of routing 101 information between network elements in different zones. The 102 proposed approach also allows to: (1) decrease the size of the link 103 state database on each node, (2) restrict the amount of routing 104 information, (3) decrease the overhead associated with flooding, and 105 (4) decrease the complexity of path selection. 107 Dovolsky, Bryskin, Awduche Expires May 2003 2 108 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 110 To make the discussions in this document concrete and practical, we 111 have used OSPF to illustrate the concepts. The solution is, however, 112 quite general and applies to other link state routing protocols, 113 such as ISIS, with very minor modifications. 115 2.1 Background: Scalability of Interior Gateway Routing Protocols 116 Context 118 Routing scalability is an important issue in operational networks. 119 This issue becomes even more acute with the advent of GMPLS, which 120 enables the use of IP routing protocols (after appropriate 121 extensions) for different types of transport networks. 123 The scalability of interior gateway routing protocols (IGPs) for IP 124 networks and other types of transport networks is a particularly 125 critical issue in operational networks, and is an important 126 requirement for major service providers. Yet, many aspects of this 127 issue have yet to be satisfactorily resolved. The most generic 128 approach to addressing the routing scalability problem is the 129 decomposition of a routing domain into multiple routing areas. This 130 approach has become an integral part of existing IGP routing 131 protocols such as OSPF [1]. Because the concept of routing areas by 132 itself is not sufficient to address all nuances of the routing 133 scalability problem, new improvements and workarounds have been 134 proposed [4, 5, 6]. The intention of virtually all of the proposed 135 solutions is to limit the amount of information advertised and to 136 limit the amount of information maintained and managed by each 137 routing engine on a network element. 139 There are many dimensions that demand consideration in attempting to 140 address the scalability of routing protocols. The main 141 manifestations of lack of scalability in routing protocols is 142 excessive consumption of CPU and memory resources on a network 143 element, and undue transaction of state information between network 144 elements to synchronize their routing databases. The transient 145 behavior of the routing protocol is another aspect that could also 146 have severe ramifications for scalability. 148 In the worst case, the impact of lack of routing protocol 149 scalability on the network itself can be devastating. In certain 150 circumstances, lack of scalability can result in severe instability 151 and a complete collapse of the network itself. Congestive collapse 152 of the routing system can also occur because of the duplication of 153 packet transmission inherent in the flooding mechanism [8]. In the 154 best case, lack of routing scalability can result in inefficient 155 network operation. Other manifestations of lack of routing 156 scalability include: long convergence time, large path computation 157 time, and slow forwarding time. 159 Path computation time is a function of the number of routes, the 160 size of the link-state database, the amount of traffic engineering 161 parameters, and the types of user preference associated with a 162 particular instance of the path computation process. All recently 164 Dovolsky, Bryskin, Awduche Expires May 2003 3 165 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 167 proposed solutions attempt to improve the routing scalability by 168 applying different algorithms to achieve one or more of the 169 following objectives: increase the number of SPF calculations [5], 170 avoid unnecessary flooding [6], restrict the database information 171 exchange to only traffic-engineering link-state advertisements [4], 172 etc. 174 It is important to note that the most common operational network 175 scenario for link state routing protocols is a single area, which 176 encompasses the entire network. In many modern networks (especially 177 those utilizing MPLS or GMPLS), the single routing area will 178 implement the traffic engineering extensions (for example [2]). In 179 such environments, the routing protocol disseminates the traditional 180 link state information as well as traffic engineering data and other 181 constraint information. Very large autonomous systems encompassing 182 entire continents containing only one routing area are in operation 183 today. 185 It is also important to note that the issue of multi-area traffic 186 engineering is an area in which the industry has not yet reached 187 consensus on an effective solution. As an example, the classical 188 approach suggested in [1] of breaking the network into multiple 189 areas cannot be used to good effect. 191 A typical service provider network is built of network elements with 192 different capabilities, such as computational resources and memory. 193 Some of them (for instance, routers installed on metro networks) may 194 have more resources for keeping large databases and performing fast 195 forwarding and path computation than the other (for instance, 196 routers installed on access networks). 198 The solution proposed in this draft is to break a single link state 199 routing area into �routing zones.� Routers and other network 200 elements within the same zone maintain a synchronized topology state 201 database among themselves. This means that network elements within 202 the same zone receive full routing information (link-sate, traffic- 203 engineering advertisements) from each other. 205 2.2 The Zone Concept 207 The zone concept refers to a �soft� partitioning of a routing area 208 into sub-domains, which allows to control the amount of routing 209 information exchange between the sub-domains in the area. The zone 210 concept also allows to decouple the advertisement of traditional 211 LSAs defined in the original OSPF specification ([1]) from the 212 advertisement of Traffic Engineering LSAs defined in the TE and 213 GMPLS extensions. 215 The zone concept allows grouping a collection of network elements 216 into a �zone� which can be viewed as a single logical network 217 entity. Each zone is associated with one or more zone border routers 218 (ZBR). A ZBR exists at the boundary between a zone and the remainder 219 of the routing area exterior to the zone. That is, a ZBR has routing 220 IGP routing adjacencies with network elements within and outside the 222 Dovolsky, Bryskin, Awduche Expires May 2003 4 223 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 225 zone. On the other hand, we say a network element is in the 226 �interior� of a zone if it maintains IGP routing adjacencies with 227 only network elements within its zone. 229 We define three types of routing visibility to support the zone 230 concept: 232 (1) full visibility, 233 (2) limited visibility, and 234 (3) zero visibility. 236 In the following discussion, when we say a �network element,� we 237 mean a network element participating in the link state routing 238 protocol. 240 To fix these ideas, let us consider two zones, say zone �A� and zone 241 �B�. We say that network elements within zone �A� have �full 242 visibility� of zone �B� if the network elements participating in the 243 link state routing protocol in zone �A� receive routing information 244 from all network elements in zone �B�. 246 We say that network elements within zone �A� have �limited 247 visibility� of zone �B� if they receive zero routing information 248 from network elements in the interior of zone �B�, with the 249 exception of LSAs from one or more Zone Border Routers (ZBRs) at the 250 boundary between the two zones. 252 Lastly, we say that network elements within zone �A� have �zero 253 visibility� of zone B if they receive zero routing information from 254 any router that belongs to zone B. 256 As a general concept, the notion of visibility defined above is not 257 symmetric. Thus, it may be the case that zone �A� can have limited 258 or zero visibility of zone �B�, while zone �B� may have full 259 visibility of zone �A�. 261 An immediate application of this concept in IP over circuit switch 262 networks occurs within the context of the peer and augmented models. 263 In such settings, some IP routers may have limited or full 264 visibility into the circuit switch network, but it may not be 265 beneficial for the circuit switch network elements to have full 266 visibility into the IP network. 268 Note, that routers within a given zone may have full visibility of 269 some zones while having limited or zero visibility of other zones. 270 For example, in an circuit switch network utilizing GMPLS, access 271 network elements within an �access zone� may have limited 272 visibility of a metro-area network zone and zero visibility of a 273 long-haul network zone, while metro-area network elements may have 274 full visibility of some access network zones and limited visibility 275 of a long-haul network zone. 277 This draft allows decoupling the advertisement of �regular LSAs� 278 from the advertisement of traffic engineering LSAs�. So that 280 Dovolsky, Bryskin, Awduche Expires May 2003 5 281 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 283 different types of visibility can be applied with respect to 284 advertisement of regular LSAs and traffic engineering LSAs. For 285 example, routers within zone �A� may have full visibility of zone 286 �B� with respect to regular LSA advertisements, but limited or zero 287 visibility with respect to traffic engineering advertisements. The 288 nature of routing visibility (full, limited or zero) between two 289 zones can be asymmetrical, as noted earlier. This important 290 characteristic of the zone concept is certainly worth emphasizing. 291 For example, routers within zone �A� may have limited visibility of 292 zone �B�, while routers with zone �B� may have full visibility of 293 zone �A�. 295 Routing visibility between two zones �A� and �B� is configured on 296 ZBR(s) that belong(s) to both zones by limiting the flooding of the 297 routing information of certain types (regular link-state 298 advertisements, traffic-engineering advertisements, or both) through 299 ZBR interfaces connecting zone �A� and zone �B�. ZBRs are 300 responsible for advertising themselves as default routes for network 301 elements within their zones, to support routing with zones that have 302 limited or zero visibility with respect to the target zone. 304 Transitive characteristics of zone visibility: If zone �A� is not 305 adjacent to zone �B� (i.e. no ZBRs in common), then we say that 306 network elements within zone �A� have full visibility of zone �B� if 307 they have full visibility of zone �C�, which is adjacent to zone �A� 308 and have full visibility of zone �B�. Otherwise, zone �A� has zero 309 visibility of zone �B�. This is an expression of the transitive 310 characteristics of zone visibility. 312 [---] 313 -------[ B ]---------- 314 | [---] | 315 | | 316 [---]Limited Visibility [---] 317 [ A ] Zone1 [ C ] 318 [---] [---] 319 | [---] | 320 -------[ZBR]---------- 321 -------[---]---------- 322 | | 323 [---] Full Visibility [---] 324 [ D ] Zone [ E ] 325 [---] [---] 326 | | 327 | [---] | 328 -------[ZBR]---------- 329 -------[---]---------- 330 | | 331 [---]Limited Visibility [---] 332 [ E ] Zone2 [ F ] 333 [---] [---] 334 | | 335 | [---] | 337 Dovolsky, Bryskin, Awduche Expires May 2003 6 338 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 340 -------[ G ]---------- 341 [---] 343 In the example above routers A, B, C are within Limited Visibility 344 Zone1. They contain full routing and traffic engineering 345 information about each other. However, the only information they 346 have about the rest of the network is the one that was generated by 347 the upper ZBR. Likewise, routers E, F and G are within Limited 348 Visibility Zone2. Routers D and E are within Full Visibility Zone. 349 They contain full routing and traffic engineering information about 350 all other routers in all zones. 352 The approach described in this draft is advantageous because it 353 allows controlling and decreasing the amount of routing information 354 and associated processing overhead on network elements. In some 355 types of network elements, it may also decrease convergence time and 356 boost the routing/forwarding performance. The traffic engineering 357 capabilities also become more scalable because constraint-based path 358 selection, and tunnel setup and management can be distributed 359 between access network elements and ZBR(s). 361 This approach does not require changes to the routing protocol 362 packet format. And it is enough to have only ZBR(s) routers 363 supporting this feature. 365 3. Proposed solution 367 A routing area may be divided into multiple zones by appropriately 368 configuring the interfaces of zone boarder routers (ZBRs). Each pair 369 of adjacent zones may be configured to have full or limited routing 370 visibility with each other. Each pair of adjacent zones may have one 371 or more ZBRs in common. Each ZBR in turn may have a number of 372 interfaces configured with one or more zone identifiers (zone IDs) 373 and flooding type. The flooding type indicates the type of routing 374 information that may be flooded across the interface. It may have 375 one of the following values: 376 . link-state advertisements only; 377 . traffic engineering advertisements only; 378 . both 380 The zone concept requires a slight modification to the OSPF Neighbor 381 state machine and flooding procedures [1]. The OSPF Neighbor state 382 machine defined in [1] should be amended as follows: 384 �10.3. The Neighbor state machine 385 � 386 State(s): ExStart 387 Event: NegotiationDone 388 New state: Exchange 389 Action: The router must list the contents of its entire 390 area link state database in the neighbor Database summary list. 392 Dovolsky, Bryskin, Awduche Expires May 2003 7 393 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 395 If an interface associated with this neighbor is configured with 396 limited flooding option and one or more zone IDs, each non self- 397 originated link-state and/or traffic engineering database entry must 398 be considered for inclusion into the Database Summary List according 399 to the following rule: 400 . non self-originated database entries must be included only if 401 they are received from incoming interfaces that have non-zero 402 overlapping list of zone IDs with the interface in question; 403 . self-originated entries must be included regardless of the 404 interface in question zone IDs; 405 . both self-originated and non self-originated database entries 406 that are disallowed to be distributed over the interface in 407 question by its configured flooding type MUST NOT be included; 409 �13.3. Next step in the flooding procedure 411 � 412 Depending upon the LSA's LS type, the LSA can be flooded out 413 only certain interfaces. These interfaces, defined by the 414 following, are called the eligible interfaces: 415 � 417 When flooding an LSA, which has just been received, each 418 outgoing interface must be considered on whether it is eligible 419 outgoing candidate or not by comparing it�s list of configured 420 zone IDs with one configured for the interface the LSA has 421 arrived on. The interface in question must be considered as 422 eligible outgoing candidate if all following conditions are 423 true: 424 . it has a non-zero overlapping list of zone IDs with the 425 incoming interface; 426 . this LSA type is allowed to be flooded over the interface in 427 question by its configured flooding type. 429 In every place in the protocol implementation, where a locally 430 originated Router LSA is needed to be flooded to a neighbor, the 431 following procedure should be performed: 433 For interfaces configured with one or more zone IDs and limited 434 flooding option the Default Route stub network link (0.0.0.0/0) must 435 be added to locally originated Router LSA. The Router LSA header 436 link number, length and checksum should be updated appropriately. 438 As a result of the described extensions routers within a particular 439 zone will receive the routing information only from routers within 440 the same zone and from other zones, which are fully visible from the 441 router. They will also receive Router LSAs originated on ZBRs that 442 belong to the zones, which the routers have limited visibility to 443 (these LSAs contain Default Route stub network links identifying 444 default routes that point to the ZBRs). They will receive no routing 445 information from routers within zones with zero routing visibility. 447 4. Distributed Traffic Engineering across multiple zones 449 Dovolsky, Bryskin, Awduche Expires May 2003 8 450 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 452 As a consequence of the flooding type definition (see 3.) the 453 limited visibility of a router to a particular zone may apply to: 454 a) link-state information; 455 b) traffic engineering information; 456 c) both. 458 If the router is presented with a request to establish a traffic 459 engineering tunnel that should go through one or more zones with the 460 limited traffic engineering visibility, the path selection and 461 tunnel setup is performed in the distributed way. Specifically, the 462 originating router can define a path for the tunnel and signal the 463 tunnel only up to one of ZBRs of a limited visibility zone towards 464 the destination. Note, that routers learn about ZBRs via Default 465 Route stub network links (0.0.0.0/0) found in received Router LSAs. 466 When the setup message arrives on the ZBR, it repeats the process. 467 Specifically, it defines the path and signal the tunnel either to 468 the destination or to ZBR of next zone towards the destination 469 depending on whether the destination is located in the zone fully 470 visible from the computing ZBR or not. This process completes when 471 the tunnel is established. 473 If a router has full visibility towards the tunnel destination as 474 far as link-state information is concerned, but has the limited 475 traffic engineering visibility, it can use the full link-state 476 visibility while deciding which ZBR to forward the tunnel setup 477 message to in case he knows about more than one. 479 5. Topological Considerations Relating to Zones 481 It may be necessary to impose some topological restrictions on the 482 connectivity of zones within a routing area, especially for 483 traditional hop by hop routing. Such restrictions are necessary to 484 in order to avoid routing anomalies such as blackholes and routing 485 loops. 487 For getting end-to-end routing connectivity and avoiding black 488 holes, some central (core) zone should be configured with full 489 visibility. Hierarchical configured zones don�t have to have direct 490 connectivity to this core zone. 492 6. Example Network 494 +--------------+ 495 | Zone A | 496 +--------------+ 497 */LF-Z1 *\ LF-Z2 498 */ *\ 499 */ *\ 500 +---------+ +---------+ 501 | Zone B | | Zone X | 502 | | | | 504 Dovolsky, Bryskin, Awduche Expires May 2003 9 505 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 507 +---------+ +---------+ 508 LF-Z3 */ \ LF-Z4 LF-Z5 / *\ LF-Z6 509 */ \ / *\ 510 +--------+ +--------+ +--------+ +--------+ 511 | Zone C | | Zone D | | Zone Y | | Zone Z | 512 | X | | | | | | | 513 +--------+ +--------+ +--------+ +--------+ 515 The above figure provides an example topology consisting of seven 516 (7) zones. While not a requirement, a likely configuration of zones 517 will be aligned with some topological or geographic regions. For 518 example, zone A may map to a network backbone, zones B and X may map 519 to local (interconnected) POPs, and zones C, D, Y and Z may map to 520 separate access networks. In such a configuration, the zones could 521 operate in the following fashion: 523 . the zones C, D, Y and Z, have a limited visibility of directly 524 attached zones, i.e., B and X respectively; 525 . the zones B and X have full visibility of directly attached 526 zones C, D, Y and Z, while having a limited visibility of zone 527 A; 528 . zone A has a full visibility of the directly connected zones B 529 and X, and therefore also a full visibility of the subtending 530 zones C, D Y and Z (and thus, becoming a backbone zone for the 531 whole network) 533 This example network can support both standard IP forwarding as well 534 as MPLS Label Switch Paths (LSPs). To illustrate, consider an LSP 535 terminating at endpoints at zone C (router C) and zone Y (router Y). 536 Since, router C does not have information about router Y, it will 537 route the LSP to ZBR of the directly attached zone (A, router LF- 538 Z3). Since router LF-Z3 does not have information about router Y, it 539 too will route the LSP to the ZBR of the directly zone (A, router 540 LF-Z1). Lastly, since router LF-Z1 has full information about all 541 routers on the network, it calculate a complete route for remaining 542 portion of the LSP. 544 7. Compatibility Issues 546 There should be no interoperability issues with routers and other 547 network elements utilizing OSPF that do not implement this proposal. 549 8. Security Considerations 551 This document does not raise new security issues beyond those that 552 exist in OSPF with traffic engineering and GMPLS extensions. The 553 method described in this document can actually enhance security 554 because it can be used to block certain types of routing data from 555 being advertised to a subset of network elements. 557 9. References 559 Dovolsky, Bryskin, Awduche Expires May 200310 560 draft-dovolsky-ccamp-ospf-limited-flooding-01.txt November 2002 562 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 564 [2] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 565 Extensions to OSPF", work in progress. 567 [3] Coltun, Rob, "The OSPF Opaque LSA Option", RFC 2370, FORE 568 Systems, July 1998. 570 [4] Venkata Naidu, "OSPF TE Only Option", draft-venkata-ospf-te- 571 only-option-00.txt, April 2002. 573 [5] A. S. Maunder, G. Choudhury, "Explicit Marking and Prioritized 574 Treatment of Specific IGP Packets for Faster IGP Convergence and 575 Improved Network Scalability and Stability", , March, 2001. 578 [6] Alex Zinin, Mike Shand, "Flooding optimizations in link-state 579 routing protocols", , March 580 2001. 582 [7] Yong Xue at all, "Carrier Optical Services Requirements", 583 , March, 2002. 585 [8] Ash et al, �Congestion Avoidance and Control for OSPF 586 Networks,�� , 587 April 2002. 589 10. Acknowledgements 590 The authors of this document would like to acknowledge the valuable 591 inputs from Lou Berger. 593 11. Author's Addresses 595 Dan Dovolsky 596 Movaz Networks 597 7926 Jones Branch Dr., Suite 615 598 McLean, VA 22102 599 Phone: (703)847-2438 600 Email: ddovolsky@movaz.com 602 Igor Bryskin 603 Movaz Networks 604 7926 Jones Branch Dr., Suite 615 605 McLean, VA 22102 606 Phone: (703)847-4208 607 Email: ibryskin@movaz.com 609 Daniel Awduche 610 Isocore Corporation 611 8201 Greensboro Drive, Suite 102 612 McLean, VA 22102 613 Phone: (703)298-5291 614 Email: awduche@awduche.com