idnits 2.17.1 draft-ietf-rtgwg-mrt-frr-architecture-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 410: '... fast-reroute MUST support Option A ...' RFC 2119 keyword, line 458: '...MRT fast-reroute SHOULD support Option...' RFC 2119 keyword, line 525: '...n the MRT Island MUST agree on a value...' RFC 2119 keyword, line 529: '...n the MRT Island MUST agree on a value...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2013) is 4079 days in the past. Is this intentional? 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: 'R' is mentioned on line 259, but not defined == Missing Reference: 'F' is mentioned on line 910, but not defined == Missing Reference: 'C' is mentioned on line 259, but not defined == Missing Reference: 'I' is mentioned on line 289, but not defined == Missing Reference: 'ABR1' is mentioned on line 759, but not defined == Missing Reference: 'ABR2' is mentioned on line 644, but not defined == Missing Reference: 'A' is mentioned on line 749, but not defined == Missing Reference: 'H' is mentioned on line 910, but not defined == Missing Reference: 'E' is mentioned on line 910, but not defined == Missing Reference: 'G' is mentioned on line 910, but not defined == Outdated reference: A later version (-04) exists of draft-enyedi-rtgwg-mrt-frr-algorithm-02 ** Downref: Normative reference to an Informational draft: draft-enyedi-rtgwg-mrt-frr-algorithm (ref. 'I-D.enyedi-rtgwg-mrt-frr-algorithm') ** Downref: Normative reference to an Informational RFC: RFC 5714 == Outdated reference: A later version (-02) exists of draft-atlas-rtgwg-mrt-mc-arch-00 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-ldp-multi-topology-06 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-ipfrr-notvia-addresses-10 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ordered-fib-09 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-01 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group A. Atlas, Ed. 3 Internet-Draft R. Kebler 4 Intended status: Standards Track Juniper Networks 5 Expires: August 28, 2013 G. Enyedi 6 A. Csaszar 7 J. Tantsura 8 Ericsson 9 M. Konstantynowicz 10 Cisco Systems 11 R. White 12 Verisign 13 M. Shand 14 February 24, 2013 16 An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees 17 draft-ietf-rtgwg-mrt-frr-architecture-02 19 Abstract 21 As IP and LDP Fast-Reroute are increasingly deployed, the coverage 22 limitations of Loop-Free Alternates are seen as a problem that 23 requires a straightforward and consistent solution for IP and LDP, 24 for unicast and multicast. This draft describes an architecture 25 based on redundant backup trees where a single failure can cut a 26 point-of-local-repair from the destination only on one of the pair of 27 redundant trees. 29 One innovative algorithm to compute such topologies is maximally 30 disjoint backup trees. Each router can compute its next-hops for 31 each pair of maximally disjoint trees rooted at each node in the IGP 32 area with computational complexity similar to that required by 33 Dijkstra. 35 The additional state, address and computation requirements are 36 believed to be significantly less than the Not-Via architecture 37 requires. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 28, 2013. 56 Copyright Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Goals for Extending IP Fast-Reroute coverage beyond LFA . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 6 77 4. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . . 8 78 5. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . . 9 79 5.1. LDP Unicast Forwarding - Avoid Tunneling . . . . . . . . . 10 80 5.2. IP Unicast Traffic . . . . . . . . . . . . . . . . . . . . 10 81 6. Protocol Extensions and Considerations: OSPF and ISIS . . . . 12 82 7. Protocol Extensions and considerations: LDP . . . . . . . . . 14 83 8. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . . . 15 84 9. Inter-Area and ABR Forwarding Behavior . . . . . . . . . . . . 16 85 10. Issues with Area Abstraction . . . . . . . . . . . . . . . . . 19 86 11. Partial Deployment and Islands of Compatible MRT FRR 87 routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 12. Network Convergence and Preparing for the Next Failure . . . . 22 89 12.1. Micro-forwarding loop prevention and MRTs . . . . . . . . 22 90 12.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . . 23 91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 24 96 16.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 99 1. Introduction 101 There is still work required to completely provide IP and LDP Fast- 102 Reroute[RFC5714] for unicast and multicast traffic. This draft 103 proposes an architecture to provide 100% coverage for unicast 104 traffic. The associated multicast architecture is described in 105 [I-D.atlas-rtgwg-mrt-mc-arch]. 107 Loop-free alternates (LFAs)[RFC5286] provide a useful mechanism for 108 link and node protection but getting complete coverage is quite hard. 109 [LFARevisited] defines sufficient conditions to determine if a 110 network provides link-protecting LFAs and also proves that augmenting 111 a network to provide better coverage is NP-hard. 112 [I-D.ietf-rtgwg-lfa-applicability] discusses the applicability of LFA 113 to different topologies with a focus on common PoP architectures. 115 While Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is defined as 116 an architecture, in practice, it has proved too complicated and 117 stateful to spark substantial interest in implementation or 118 deployment. Academic implementations [LightweightNotVia] exist and 119 have found the address management complexity high (but no 120 standardization has been done to reduce this). 122 A different approach is needed and that is what is described here. 123 It is based on the idea of using disjoint backup topologies as 124 realized by Maximally Redundant Trees (described in 125 [LightweightNotVia]); the general architecture can also apply to 126 future improved redundant tree algorithms. 128 1.1. Goals for Extending IP Fast-Reroute coverage beyond LFA 130 Any scheme proposed for extending IPFRR network topology coverage 131 beyond LFA, apart from attaining basic IPFRR properties, should also 132 aim to achieve the following usability goals: 134 o ensure maximum physically feasible link and node disjointness 135 regardless of topology, 137 o automatically compute backup next-hops based on the topology 138 information distributed by link-state IGP, 140 o do not require any signaling in the case of failure and use pre- 141 programmed backup next-hops for forwarding, 143 o introduce minimal amount of additional addressing and state on 144 routers, 146 o enable gradual introduction of the new scheme and backward 147 compatibility, 149 o and do not impose requirements for external computation. 151 2. Terminology 153 2-connected: A graph that has no cut-vertices. This is a graph 154 that requires two nodes to be removed before the network is 155 partitioned. 157 2-connected cluster: A maximal set of nodes that are 2-connected. 159 2-edge-connected: A network graph where at least two links must be 160 removed to partition the network. 162 ADAG: Almost Directed Acyclic Graph - a graph that, if all links 163 incoming to the root were removed, would be a DAG. 165 block: Either a 2-connected cluster, a cut-edge, or an isolated 166 vertex. 168 cut-link: A link whose removal partitions the network. A cut-link 169 by definition must be connected between two cut-vertices. If 170 there are multiple parallel links, then they are referred to as 171 cut-links in this document if removing the set of parallel links 172 would partition the network. 174 cut-vertex: A vertex whose removal partitions the network. 176 DAG: Directed Acyclic Graph - a graph where all links are directed 177 and there are no cycles in it. 179 GADAG: Generalized ADAG - a graph that is the combination of the 180 ADAGs of all blocks. 182 Maximally Redundant Trees (MRT): A pair of trees where the path 183 from any node X to the root R along the first tree and the path 184 from the same node X to the root along the second tree share the 185 minimum number of nodes and the minimum number of links. Each 186 such shared node is a cut-vertex. Any shared links are cut-links. 187 Any RT is an MRT but many MRTs are not RTs. 189 network graph: A graph that reflects the network topology where all 190 links connect exactly two nodes and broadcast links have been 191 transformed into the standard pseudo-node representation. 193 Redundant Trees (RT): A pair of trees where the path from any node 194 X to the root R along the first tree is node-disjoint with the 195 path from the same node X to the root along the second tree. 196 These can be computed in 2-connected graphs. 198 3. Maximally Redundant Trees (MRT) 200 In the last few years, there's been substantial research on how to 201 compute and use redundant trees. Redundant trees are directed 202 spanning trees that provide disjoint paths towards their common root. 203 These redundant trees only exist and provide link protection if the 204 network is 2-edge-connected and node protection if the network is 205 2-connected. Such connectiveness may not be the case in real 206 networks, either due to architecture or due to a previous failure. 207 The work on maximally redundant trees has added two useful pieces 208 that make them ready for use in a real network. 210 o Computable regardless of network topology: The maximally redundant 211 trees are computed so that only the cut-edges or cut-vertices are 212 shared between the multiple trees. 214 o Computationally practical algorithm is based on a common network 215 topology database. Algorithm variants can compute in O( e) or O(e 216 + n log n), as given in [I-D.enyedi-rtgwg-mrt-frr-algorithm]. 218 There is, of course, significantly more in the literature related to 219 redundant trees and even fast-reroute, but the formulation of the 220 Maximally Redundant Trees (MRT) algorithm makes it very well suited 221 to use in routers. 223 A known disadvantage of MRT, and redundant trees in general, is that 224 the trees do not necessarily provide shortest detour paths. The use 225 of the shortest-path-first algorithm in tree-building and including 226 all links in the network as possibilities for one path or another 227 should improve this. Modeling is underway to investigate and compare 228 the MRT alternates to the optimal 229 [I-D.enyedi-rtgwg-mrt-frr-algorithm]. Providing shortest detour 230 paths would require failure-specific detour paths to the 231 destinations, but the state-reduction advantage of MRT lies in the 232 detour being established per destination (root) instead of per 233 destination AND per failure. 235 The specific algorithms to compute MRTs as well as the logic behind 236 that algorithm and alternative computational approaches are given in 237 detail in [I-D.enyedi-rtgwg-mrt-frr-algorithm]. Those interested are 238 highly recommended to read that document. This document describes 239 how the MRTs can be used and not how to compute them. 241 The most important thing to understand about MRTs is that for each 242 pair of destination-routed MRTs, there is a path from every node X to 243 the destination D on the Blue MRT that is as disjoint as possible 244 from the path on the Red MRT. The two paths along the two MRTs to a 245 given destination-root of a 2-connected graph are node-disjoint and 246 link-disjoint, while in any non-2-connected graph, only the cut- 247 vertices and cut-edges can be contained by both of the paths. 249 For example, in Figure 1, there is a network graph that is 250 2-connected in (a) and associated MRTs in (b) and (c). One can 251 consider the paths from B to R; on the Blue MRT, the paths are 252 B->F->D->E->R or B->C->D->E->R. On the Red MRT, the path is B->A->R. 253 These are clearly link and node-disjoint. These MRTs are redundant 254 trees because the paths are disjoint. 256 [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| 257 | | | | ^ | | | 258 | | | V | | V V 259 [R] [F] [C] [R] [F] [C] [R] [F] [C] 260 | | | ^ ^ ^ | | 261 | | | | | | V | 262 [A]---[B]---| [A]-->[B]---| [A]---[B]<--| 264 (a) (b) (c) 265 a 2-connected graph Blue MRT towards R Red MRT towards R 267 Figure 1: A 2-connected Network 269 By contrast, in Figure 2, the network in (a) is not 2-connected. If 270 F, G or the link F<->G failed, then the network would be partitioned. 271 It is clearly impossible to have two link-disjoint or node-disjoint 272 paths from G, I or J to R. The MRTs given in (b) and (c) offer paths 273 that are as disjoint as possible. For instance, the paths from B to 274 R are the same as in Figure 1 and the path from G to R on the Blue 275 MRT is G->F->D->E->R and on the Red MRT is G->F->B->A->R. 277 [E]---[D]---| 278 | | | |----[I] 279 | | | | | 280 [R]---[C] [F]---[G] | 281 | | | | | 282 | | | |----[J] 283 [A]---[B]---| 285 (a) 286 a non-2-connected graph 288 [E]<--[D]<--| [E]-->[D]---| 289 | ^ | [I] | | [I] 290 V | | ^ V V | 291 [R]<--[C] [F]<--[G] | [R]---[C] [F]<--[G] | 292 ^ ^ | | ^ | | ^ V 293 | | |--->[J] | V | |----[J] 294 [A]-->[B]---| [A]<--[B]<--| 296 (b) (c) 297 Blue MRT towards R Red MRT towards R 299 Figure 2: A non-2-connected network 301 4. Maximally Redundant Trees (MRT) and Fast-Reroute 303 In normal IGP routing, each router has its shortest-path-tree to all 304 destinations. From the perspective of a particular destination, D, 305 this looks like a reverse SPT (rSPT). To use maximally redundant 306 trees, in addition, each destination D has two MRTs associated with 307 it; by convention these will be called the blue and red MRTs. 309 Any IP/LDP fast-reroute technique beyond LFA requires an additional 310 dataplane procedure, such as an additional forwarding mechanism. The 311 well-known options are tunneling (e.g. 312 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] or 313 [I-D.ietf-rtgwg-remote-lfa]), per-interface forwarding (e.g. Loop- 314 Free Failure Insensitive Routing in [EnyediThesis]), and multi- 315 topology forwarding. MRT is realized by using multi-topology 316 forwarding. There is a Blue MRT forwarding topology and a Red MRT 317 forwarding topology. 319 MRTs are practical to maintain redundancy even after a single link or 320 node failure. If a pair of MRTs is computed rooted at each 321 destination, all the destinations remain reachable along one of the 322 MRTs in the case of a single link or node failure. 324 When there is a link or node failure affecting the rSPT, each node 325 will still have at least one path via one of the MRTs to reach the 326 destination D. For example, in Figure 2, C would normally forward 327 traffic to R across the C<->R link. If that C<->R link fails, then C 328 could use either the Blue MRT path C->D->E->R or the Red MRT path 329 C->B->A->R. 331 As is always the case with fast-reroute technologies, forwarding does 332 not change until a local failure is detected. Packets are forwarded 333 along the shortest path. The appropriate alternate to use is pre- 334 computed. [I-D.enyedi-rtgwg-mrt-frr-algorithm] describes exactly how 335 to determine whether the Blue MRT next-hops or the Red MRT next-hops 336 should be the MRT alternate next-hops for a particular primary next- 337 hop N to a particular destination D. 339 MRT alternates are always available to use, unless the network has 340 been partitioned. It is a local decision whether to use an MRT 341 alternate, a Loop-Free Alternate or some other type of alternate. 342 When a network needs to use a micro-loop prevention mechanism 343 [RFC5715] such as Ordered FIB[I-D.ietf-rtgwg-ordered-fib] or Farside 344 Tunneling[RFC5715], then the whole IGP area needs to have alternates 345 available so that the micro-loop prevention mechanism, which requires 346 slower network convergence, can take the necessary time without 347 impacting traffic badly. 349 As described in [RFC5286], when a worse failure than is anticipated 350 happens, using LFAs that are not downstream neighbors can cause 351 micro-looping. An example is given of link-protecting alternates 352 causing a loop on node failure. Even if a worse failure than 353 anticipated happened, the use of MRT alternates will not cause 354 looping. Therefore, while node-protecting LFAs may be prefered, an 355 the certainty that no alternate-induced looping will occur is an 356 advantage of using MRT alternates when the available node-protecting 357 LFA is not a downstream path. 359 5. Unicast Forwarding with MRT Fast-Reroute 361 With LFA, there is no need to tunnel unicast traffic, whether IP or 362 LDP. The traffic is simply sent to an alternate. As mentioned 363 earlier in Section 4, MRT needs multi-topology forwarding. 364 Unfortunately, neither IP nor LDP provide extra bits for a packet to 365 indicate its topology. 367 Once the MRTs are computed, the two sets of MRTs are seen by the 368 forwarding plane as essentially two additional topologies. The same 369 considerations apply for forwarding along the MRTs as for handling 370 multiple topologies. 372 5.1. LDP Unicast Forwarding - Avoid Tunneling 374 For LDP, it is very desirable to avoid tunneling because, for at 375 least node protection, tunneling requires knowledge of remote LDP 376 label mappings and thus requires targeted LDP sessions and the 377 associated management complexity. There are two different mechanisms 378 that can be used. 380 1. Option A - Encode MT-ID in Labels: In addition to sending a 381 single label for a FEC, a router would provide two additional 382 labels with the MT-IDs associated with the Blue MRT or Red MRT 383 forwarding topologies. This is very simple for hardware support. 384 It does reduce the label space for other uses. It also increases 385 the memory to store the labels and the communication required by 386 LDP. 388 2. Option B - Create Topology-Identification Labels: Use the label- 389 stacking ability of MPLS and specify only two additional labels - 390 one for each associated MRT color - by a new FEC type. When 391 sending a packet onto an MRT, first swap the LDP label and then 392 push the topology-identification label for that MRT color. When 393 receiving a packet with a topology-identification label, pop it 394 and use it to guide the next-hop selection in combination with 395 the next label in the stack; then swap the remaining label, if 396 appropriate, and push the topology-identification label for the 397 next-hop. This has minimal usage of additional labels, memory 398 and LDP communication. It does increase the size of packets and 399 the complexity of the required label operations and look-ups. 400 This can use the same mechanisms as are needed for context-aware 401 label spaces. 403 Note that with LDP unicast forwarding, regardless of whether 404 topology-identification label or encoding topology in label is used, 405 no additional loopbacks per router are required. This is because LDP 406 labels are used on a hop-by-hop basis to identify MRT-blue and MRT- 407 red forwading topologies. 409 For greatest hardware compatibility, routers implementing MRT LDP 410 fast-reroute MUST support Option A of encoding the MT-ID in the 411 labels. The extensions to indicate an MT-ID for a FEC are described 412 in Section 3.2.1 of [I-D.ietf-mpls-ldp-multi-topology] 414 5.2. IP Unicast Traffic 416 For IP, there is no currently practical alternative except tunneling. 417 The tunnel egress could be the original destination in the area, the 418 next-next-hop, etc.. If the tunnel egress is the original 419 destination router, then the traffic remains on the redundant tree 420 with sub-optimal routing. If the tunnel egress is the next-next-hop, 421 then protection of multi-homed prefixes and node-failure for ABRs is 422 not available. Selection of the tunnel egress is a router-local 423 decision. 425 There are three options available for marking IP packets with which 426 MRT it should be forwarded in. 428 1. Tunnel IP packets via an LDP LSP. This has the advantage that 429 more installed routers can do line-rate encapsulation and 430 decapsulation. Also, no additional IP addresses would need to be 431 allocated or signaled. 433 A. Option A - LDP Destination-Topology Label: Use a label that 434 indicates both destination and MRT. This method allows easy 435 tunneling to the next-next-hop as well as to the IGP-area 436 destination. For a proxy-node, the destination to use is the 437 non-proxy-node immediately before the proxy-node on that 438 particular color MRT. 440 B. Option B - LDP Topology Label: Use a Topology-Identifier 441 label on top of the IP packet. This is very simple. If 442 tunneling to a next-next-hop is desired, then a two-deep 443 label stack can be used with [ Topology-ID label, Next-Next- 444 Hop Label ]. 446 2. Tunnel IP packets in IP. Each router supporting this option 447 would announce two additional loopback addresses and their 448 associated MRT color. Those addresses are used as destination 449 addresses for MRT-blue and MRT-red IP tunnels respectively. They 450 allow the transit nodes to identify the traffic as being 451 forwarded along either MRT-blue or MRT-red tree topology to reach 452 the tunnel destination. Announcements of these two additional 453 loopback addresses per router with their MRT color requires IGP 454 extensions. 456 For greatest hardware compatibility and ease in removing the MRT- 457 topology marking at area/level boundaries, routers that support MPLS 458 and implement IP MRT fast-reroute SHOULD support Option A - using an 459 LDP label that indicates the destination and MT-ID. 461 For proxy-nodes associated with one or more multi-homed prefixes, 462 there is no router associated with the proxy-node, so its loopbacks 463 can't be known or used. Instead, the loopback addresses of the 464 routers that are attached to the proxy-node can be used. One of 465 those routers will be on the Red MRT and the other on the Blue MRT. 466 The MRT-red loopback of the first router would be used to reach the 467 router on the Red MRT and similarly the MRT-blue loopback of the 468 second router would be used. The routers connected to the proxy-node 469 are the end of the area/level and can decapsulate the traffic and 470 properly forward it into the next area. 472 6. Protocol Extensions and Considerations: OSPF and ISIS 474 There are two possible approaches to what additional information to 475 distribute in the IGP. The first is to allow full flexibility in all 476 information and distribute whichever values and combinations are 477 desired. The second is to simply distribute flags indicating a 478 particular well-known profile is supported. Thus the MRT Island 479 Creation process is trivial. The profile approach is recommended, 480 with the added flexibility of being able to specify more specific 481 information if necessary and supported. 483 For example, a simple profile "metric-insensitive MRT unicast fast- 484 reroute via LDP" could specify: 486 MRT Island Creation: Only include other routers advertising this 487 profile. 489 MRT Algorithm ID: The MRT Lowpoint algorithm defined in 490 [I-D.enyedi-rtgwg-mrt-frr-algorithm]. 492 Red MRT MT-ID: The Red MRT MT-ID is the single well-known value 493 allocated by IANA from the OSPF, ISIS, LDP and PIM MT-ID spaces. 495 Blue MRT MT-ID: The Blue MRT MT-ID is the single well-known value 496 allocated by IANA from the OSPF, ISIS, LDP and PIM MT-ID spaces. 498 GADAG Root Election Priority: Pick the router with the lowest 499 router ID to be the GADAG root. 501 Forwarding Mechanisms for IP: Use IP-in-LDP. 503 MRT Capabilities: Computes MRTs, IP Fast-Reroute, LDP Fast-Reroute 505 The following captures an initial understanding of the aspects that 506 must be considered to fully form a profile to advertise. For some 507 profiles, associated information may need to be distributed, such as 508 GADAG Root Election Priority, Red MRT Loopback Address, Blue MRT 509 Loopback Address, or MRT Algorithm ID. 511 MRT Island Creation ID: This identifies the process that the router 512 uses to form an MRT Island. By advertising an ID for the process, 513 it is possible to have different processes in the future. It may 514 be desirable to advertise a list ordered by preference to allow 515 transitions. 517 MRT Algorithm ID: This identifies the particular MRT algorithm used 518 by the router. By having an Algorithm ID, it is possible to 519 change the algorithm used or use different ones in different 520 networks. It may be desirable to advertise a list ordered by 521 preference to allow transitions. 523 Red MRT MT-ID: This specifies the MT-ID to be associated with the 524 Red MRT forwarding topology. It is needed for use in signaling. 525 All routers in the MRT Island MUST agree on a value. 527 Blue MRT MT-ID: This specifies the MT-ID to be associated with the 528 Blue MRT forwarding topology. It is needed for use in signaling. 529 All routers in the MRT Island MUST agree on a value. 531 GADAG Root Election Priority: This specifies the priority of the 532 router for being used as the GADAG root of its island. A GADAG 533 root is elected from the set of routers with the highest priority; 534 ties are broken based upon highest Router ID. The sensitivity of 535 the MRT Algorithms to GADAG root selection is still being 536 evaluated. This provides the network operator with a knob to 537 force particular GADAG root selection. 539 Forwarding Mechanism for IP: This specifies which forwarding 540 mechanisms the router supports for IP traffic. An MRT island must 541 support a common set of forwarding mechanisms, which may be less 542 than the full set advertised. Multiple forwarding mechanisms may 543 be specified, such as IP-in-IPv4, IP-in-IPv6 or IP-in-LDP Label. 544 None is also an option. 546 Red MRT Loopback Address: This provides the router's loopback 547 address to reach the router via the Red MRT forwarding topology. 548 It can, of course, be specified for both IPv4 and IPv6. 550 Blue MRT Loopback Address: This provides the router's loopback 551 address to reach the router via the Blue MRT forwarding topology. 552 It can, of course, be specified for both IPv4 and IPv6. 554 MRT Capabilities Available: This is the set of capabilities that 555 the router is configured to support. 557 MRT Capabilities Required: This is the set of capabilities that 558 other routers must have available to be added into the MRT island. 560 MRT Capability: Computes MRTs: The router can compute MRTs. 562 MRT Capability: IP Fast-Reroute: The router can use the computed 563 MRTs for IP fast-reroute. 565 MRT Capability: LDP Fast-Reroute: The router can use the computed 566 MRTs for LDP fast-reroute. 568 MRT Capability: PIM Fast-Reroute: The router can use the computed 569 MRTs for PIM fast-reroute. 571 MRT Capability: mLDP Fast-Reroute: The router can use the computed 572 MRTs for mLDP fast-reroute. 574 MRT Capability: PIM Global Protection: The router can use the 575 computed MRTs for PIM Global Protection 1+1. 577 MRT Capability: mLDP Global Protection: The router can use the 578 computed MRTs for mLDP Global Protection 1+1. 580 The assumption is that a router will form an MRT island, compute MRTs 581 within that island, and then use those MRTs for the purposes 582 specified in the profile. If multiple profiles are supported with 583 different purposes (e.g. mLDP Global Protection), then the router may 584 use a different profile and associated MRT island to be used for the 585 purposes in that different profile. If a router wanted to form 586 multiple MRT islands for different application purposes, that could 587 be done by specifying different Red MRT MT-ID and Blue MRT MT-IDs. 589 As with LFA, it is expected that OSPF Virtual Links will not be 590 supported. 592 7. Protocol Extensions and considerations: LDP 594 Capability negotiation in LDP is needed to indicate support for MRT; 595 having this explicit allows the use of MRT-specific signaling 596 extensions. A router also needs to indicate, via FEC advertisement, 597 whether it supports LDP Destination-Topology Labels, LDP Topology 598 Labels, or both. Since the label or labels are swapped at each LSR, 599 consistency across the network is not required. 601 If both mechanisms are supported, then if a Destination-Topology 602 label is provided for a FEC, that should be used so that an ABR/LBR 603 can indicate the appropriate labels, as discussed in Section 604 Section 9. 606 8. Multi-homed Prefixes 608 One advantage of LFAs that is necessary to preserve is the ability to 609 protect multi-homed prefixes against ABR failure. For instance, if a 610 prefix from the backbone is available via both ABR A and ABR B, if A 611 fails, then the traffic should be redirected to B. This can also be 612 done for backups via MRT. 614 This generalizes to any multi-homed prefix. A multi-homed prefix 615 could be: 617 o An out-of-area prefix announced by more than one ABR, 619 o An AS-External route announced by 2 or more ASBRs, 621 o A prefix with iBGP multipath to different ASBRs, 623 o etc. 625 For each prefix, the attached ABRs are selected and a proxy-node is 626 created connected to those ABRs. If there exist multiple multi-homed 627 prefixes that share the same connectivity and costs to each of those 628 ABRs, then a single proxy-node can be used to represent the set. An 629 example of this is shown in Figure 3. 631 2 2 2 2 632 A----B----C A----B----C 633 2 | | 2 2 | | 2 634 | | | | 635 [ABR1] [ABR2] [ABR1] [ABR2] 636 | | | | 637 p,10 p,15 10 |---[P]---| 15 639 (a) Initial topology (b)with proxy-node 641 A<---B<---C A--->B--->C 642 | ^ ^ | 643 V | | V 644 [ABR1] [ABR2] [ABR1] [ABR2] 645 | | 646 |-->[P] [P]<--| 648 (c) Blue MRT (d) Red MRT 650 Figure 3: Prefixes Advertised by Multiple ABRs 652 The proxy-nodes and associated links are added to the network 653 topology after all real links have been assigned to a direction and 654 before the actual MRTs are computed. Proxy-nodes cannot be transited 655 when computing the MRTs. In addition to computing the pair of MRTs 656 associated with each router destination D in the area, a pair of MRTs 657 can be computed for each such proxy-node to fully protect against ABR 658 failure. 660 Each ABR or attaching router must remove the MRT marking[see 661 Section 5] and then forward the traffic outside of the area (or 662 island of MRT-fast-reroute-supporting routers). 664 If ASBR protection is desired, this has additonal complexities if the 665 ASBRs are in different areas. Similarly, protecting labeled BGP 666 traffic in the event of an ASBR failure has additional complexities 667 due to the per-ASBR label spaces involved. 669 9. Inter-Area and ABR Forwarding Behavior 671 In regular forwarding, packets destined outside the area arrive at 672 the ABR and the ABR forwards them into the other area because the 673 next-hops from the area with the best route (according to tie- 674 breaking rules) are used by the ABR. The question is then what to do 675 with packets marked with an MRT that are received by the ABR. 677 For unicast fast-reroute, the need to stay on an MRT forwarding 678 topology terminates at the ABR/LBR whose best route is via a 679 different area/level. It is highly desirable to go back to the 680 default forwarding topology when leaving an area/level. There are 681 three basic reasons for this. First, the default topology uses 682 shortest paths; the packet will thus take the shortest possible route 683 to the destination. Second, this allows failures that might appear 684 in multiple areas (e.g. ABR/LBR failures) to be separately 685 identified and repaired around. Third, the packet can be fast- 686 rerouted again, if necessary, due to a failure in a different area. 688 An ABR/LBR that receives a packet marked with an MRT towards a 689 destination in another area/level should forward the MRT marked 690 packet in the area/level with the best route along its associated 691 MRT. If the packet came from that area/level, this correctly avoids 692 the failure. 694 How does an ABR/LBR ensure that MRT-marked packets do not arrive at 695 the ABR/LBR? There are two different mechanisms depending upon the 696 forwarding mechanism being used. 698 If the LDP label encodes the MT-ID as well as the destination, then 699 the ABR/LBR is responsible for advertising a particular label to each 700 neighbor. Additionally, an LDP label is associated with an MT-ID due 701 to the MT FEC that was used and not due to any intrisic particular 702 value for the label. Assume that an ABR/LBR has allocated three 703 labels for a particular destination; those labels are L_primary, 704 L_blue, and L_red. When the ABR/LBR advertises label bindings to 705 routers in the area with the best route to the destination, the ABR/ 706 LBR provides L_primary for the default topology, L_blue for the Blue 707 MRT MT-ID and L_red for the Red MRT MT-ID, exactly as expected. 708 However, when the ABR/LBR advertises label bindings to routers in 709 other areas, the ABR/LBR advertises L_primary for the default 710 topology, for the Blue MRT MT-ID, and for the Red MRT MT-ID. The 711 ABR/LBR installs next-hops from the best area for L_primary based on 712 the default topology, for L_blue based on the Blue MRT forwarding 713 topology, and for L_red based on the Red MRT forwarding topology. 714 Therefore, packets from the non-best area will arrive at the ABR/LBR 715 with a label L_primary and will be forwarded into the best area along 716 the default topology. By controlling what labels are advertised, the 717 ABR/LBR can thus enforce that packets exiting the area do so on the 718 shortest-path default topology. 720 If IP-in-IP forwarding is used, then the ABR/LBR behavior is 721 dependent upon the outermost IP address. If the outermost IP address 722 is an MRT loopback address of the ABR/LBR, then the packet is 723 decapsulated and forwarded based upon the inner IP address, which 724 should go on the default SPT topology. If the outermost IP address 725 is not an MRT loopback address of the ABR/LBR, then the packet is 726 simply forwarded along the associated forwarding topology. A PLR 727 sending traffic to a destination outside its local area/level will 728 pick the MRT and use the associated MRT loopback address of the ABR/ 729 LBR immediately before the proxy-node on that MRT. 731 Thus, regardless of which of these two forwarding mechanisms are 732 used, there is no need for additional computation or per-area 733 forwarding state. 735 +----[C]---- --[D]--[E] --[D]--[E] 736 | \ / \ / \ 737 p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+ 738 | / \ / | \ / | 739 +----[B]---- --[F]--[G] | --[F]--[G] | 740 | | 741 | other | 742 +----------[p]-------+ 743 area 745 (a) Example topology (b) Proxy node view in Area 0 nodes 747 +----[C]<--- [D]->[E] 748 V \ \ 749 +-[A] Area 10 [ABR1] Area 0 [H]-+ 750 | ^ / / | 751 | +----[B]<--- [F]->[G] V 752 | | 753 +------------->[p]<--------------+ 755 (c) rSPT towards destination p 757 ->[D]->[E] -<[D]<-[E] 758 / \ / \ 759 [ABR1] Area 0 [H]-+ +-[ABR1] [H] 760 / | | \ 761 [F]->[G] V V -<[F]<-[G] 762 | | 763 | | 764 [p]<------+ +--------->[p] 766 (d) Blue MRT in Area 0 (e) Red MRT in Area 0 768 Figure 4: ABR Forwarding Behavior and MRTs 770 The other potential forwarding mechanisms require additional 771 computation by the penultimate router along the in-local-area MRT 772 immediately before the ABR/LBR is reached. The penultimate router 773 can determine that the ABR/LBR will forward the packet out of area/ 774 level and, in that case, the penultimate router can remove the MRT 775 marking but still forward the packet along the MRT next-hop to reach 776 the ABR. For instance, in Figure 4, if node H fails, node E has to 777 put traffic towards prefix p onto the red MRT. But since node D 778 knows that ABR1 will use a best from another area, it is safe for D 779 to remove the MRT marking and just send the packet to ABR1 still on 780 the red MRT but unmarked. ABR1 will use the shortest path in Area 781 10. 783 In all cases for ISIS and most cases for OSPF, the penultimate router 784 can determine what decision the adjacent ABR will make. The one case 785 where it can't be determined is when two ASBRs are in different non- 786 backbone areas attached to the same ABR, then the ASBR's Area ID may 787 be needed for tie-breaking (prefer the route with the largest OPSF 788 area ID) and the Area ID isn't announced as part of the ASBR link- 789 state advertisement (LSA). In this one case, suboptimal forwarding 790 along the MRT in the other area would happen. If this is a realistic 791 deployment scenario, OSPF extensions could be considered. 793 10. Issues with Area Abstraction 795 MRT fast-reroute provides complete coverage in a area that is 796 2-connected. Where a failure would partition the network, of course, 797 no alternate can protect against that failure. Similarly, there are 798 ways of connecting multi-homed prefixes that make it impractical to 799 protect them without excessive complexity. 801 50 802 |----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0: 803 | | ABR 1, ABR 2, C, D 804 | | 805 | | Area 20: A, ASBR X 806 | | 807 p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y 808 5 p is a Type 1 AS-external 810 Figure 5: AS external prefixes in different areas 812 Consider the network in Figure 5 and assume there is a richer 813 connective topology that isn't shown, where the same prefix is 814 announced by ASBR X and ASBR Y which are in different non-backbone 815 areas. If the link from A to ASBR X fails, then an MRT alternate 816 could forward the packet to ABR 1 and ABR 1 could forward it to D, 817 but then D would find the shortest route is back via ABR 1 to Area 818 20. The only real way to get it from A to ASBR Y is to explicitly 819 tunnel it to ASBR Y. 821 Tunnelling to the backup ASBR is for future consideration. The 822 previously proposed PHP approach needs to have an exception if BGP 823 policies (e.g. BGP local preference) determines which ASBR to use. 824 Consider the case in Figure 6. If the link between A and ASBR X (the 825 preferred border router) fails, A can put the packets to p onto an 826 MRT alternate, even tunnel it towards ASBR Y. Node B, however, must 827 not remove the MRT marking in this case, as nodes in Area 0, 828 including ASBR Y itself would not know that their preferred ASBR is 829 down. 831 Area 20 BB Area 0 832 p ---[ASBR X]-X-[A]---[B]---[ABR 1]---[D]---[ASBR Y]--- p 834 BGP prefers ASBR X for prefix p 836 Figure 6: Failure of path towards ASBR preferred by BGP 838 The fine details of how to solve multi-area external prefix cases, or 839 identifying certain cases as too unlikely and too complex to protect 840 is for further consideration. 842 11. Partial Deployment and Islands of Compatible MRT FRR routers 844 A natural concern with new functionality is how to have it be useful 845 when it is not deployed across an entire IGP area. In the case of 846 MRT FRR, where it provides alternates when appropriate LFAs aren't 847 available, there are also deployment scenarios where it may make 848 sense to only enable some routers in an area with MRT FRR. A simple 849 example of such a scenario would be a ring of 6 or more routers that 850 is connected via two routers to the rest of the area. 852 First, a computing router S must determine its local island of 853 compatible MRT fast-reroute routers. A router that has a common 854 profile flag and is connected either to S or to another router 855 already determined to be in S's local island can be added to S's 856 local island. 858 Destinations inside the local island can obviously use MRT 859 alternates. Destinations outside the local island can be treated 860 like a multi-homed prefix with caveats to avoid looping. For LDP 861 labels including both destination and topology, the routers at the 862 borders of the local island need to originate labels for the original 863 FEC and the associated MRT-specific labels. Packets sent to an LDP 864 label marked as blue or red MRT to a destination outside the local 865 island will have the last router in the local island swap the label 866 to one for the destination and forward the packet along the outgoing 867 interface on the MRT towards a router outside the local island that 868 was represented by the proxy-node. 870 For IP in IP encapsulations, remote destinations' loopback addresses 871 for the MRTs cannot be used, even if they were available. Instead, 872 the MRT loopback address of the router attached to a proxy-node, 873 which represents destinations outside the local island, can be used. 874 Packets sent to the router's MRT loopback address will have their 875 outer IP header removed and will need to be explicitly forwarded 876 along the outgoing interface on the MRT towards a router outside the 877 local island that was represented by the proxy-node. This behavior 878 requires essentially remembering the MT-ID indicated by the outer IP 879 address. An alternate option would be to advertise different 880 loopback addresses to be associated with the proxy-node; the outer IP 881 address would still be removed but it would indicate the outgoing 882 interface to use and no lookup would be necessary on the internal IP 883 address while maintaining MT-ID context. 885 A key question is which routers outside the MRT island can packets be 886 forwarded to so that they are not forwarded back into the MRT island. 887 An example of the necessary network graph transformations are given 888 in Figure 7. There are two parts to the computation. First, the MRT 889 island is collapsed into a single node; this assumes that the cost of 890 transiting the MRT island is nothing and is pessimistic but allows 891 for simpler computation. Then, for each destination (other than the 892 MRT island), the routers adjacent to the MRT island are checked to 893 see if they are loop-free with respect to the MRT island and the 894 destination. The loop-free neighbors of the MRT island that are 895 closest to the destination are selected. Then, a graph of just the 896 MRT island is augmented with proxy-nodes that are attached via the 897 outgoing interfaces to the selected loop-free neighbors. Finally, 898 the MRTs rooted at each proxy-node are computed on that augmented MRT 899 island graph. Essentially, the MRT island must have a loop-free 900 neighbor to be able to have an alternate. 902 [G]---[E]---(B)---(C)---(D) 903 | \ | | | 904 | \ | | | 905 | \ | | | 906 [H]---[F]---(A)---(S)----| 908 (1) Network Graph with Partial Deployment 910 [E],[F],[G],[H] : No support for MRT-FRR 911 (A),(B),(C),(D),(S): MRT Island - supports MRT-FRR 913 [G]---[E]----| |---(B)---(C)---(D) 914 | \ | | | | | 915 | \ | ( MRT Island ) [ proxy ] | | 916 | \ | | | | | 917 [H]---[F]----| |---(A)---(S)----| 919 (2) Graph for determining (3) Graph for MRT computation 920 loop-free neighbors 922 Figure 7: Computing alternates to destinations outside the MRT Island 924 Naturally, there are more complicated options to improve coverage, 925 such as connecting multiple MRT islands across tunnels, but it is not 926 clear that the additional complexity is necessary. 928 12. Network Convergence and Preparing for the Next Failure 930 After a failure, MRT detours ensure that packets reach their intended 931 destination while the IGP has not reconverged onto the new topology. 932 As link-state updates reach the routers, the IGP process calculates 933 the new shortest paths. Two things need attention: micro-loop 934 prevention and MRT re-calculation. 936 12.1. Micro-forwarding loop prevention and MRTs 938 As is well known[RFC5715], micro-loops can occur during IGP 939 convergence; such loops can be local to the failure or remote from 940 the failure. Managing micro-loops is an orthogonal issue to having 941 alternates for local repair, such as MRT fast-reroute provides. 943 There are two possible micro-loop prevention mechanism discussed in 944 [RFC5715]. The first is Ordered FIB [I-D.ietf-rtgwg-ordered-fib]. 945 The second is Farside Tunneling which requires tunnels or an 946 alternate topology to reach routers on the farside of the failure. 948 Since MRTs provide an alternate topology through which traffic can be 949 sent and which can be manipulated separately from the SPT, it is 950 possible that MRTs could be used to support Farside Tunneling. 951 Details of how to do so are outside of this document. 953 12.2. MRT Recalculation 955 When a failure event happens, traffic is put by the PLRs onto the MRT 956 topologies. After that, each router recomputes its shortest path 957 tree (SPT) and moves traffic over to that. Only after all the PLRs 958 have switched to using their SPTs and traffic has drained from the 959 MRT topologies should each router install the recomputed MRTs into 960 the FIBs. 962 At each router, therefore, the sequence is as follows: 964 1. Receive failure notification 966 2. Recompute SPT 968 3. Install new SPT 970 4. Recompute MRTs 972 5. Wait configured period for all routers to be using their SPTs and 973 traffic to drain from the MRTs. 975 6. Install new MRTs. 977 While the recomputed MRTs are not installed in the FIB, protection 978 coverage is lowered. Therefore, it is important to recalculate the 979 MRTs and install them quickly. 981 13. Acknowledgements 983 The authors would like to thank Hannes Gredler, Jeff Tantsura, Ted 984 Qian, Kishore Tiruveedhula, Santosh Esale, Nitin Bahadur, Harish 985 Sitaraman and Raveendra Torvi for their suggestions and review. 987 14. IANA Considerations 989 This doument includes no request to IANA. 991 15. Security Considerations 993 This architecture is not currently believed to introduce new security 994 concerns. 996 16. References 998 16.1. Normative References 1000 [I-D.enyedi-rtgwg-mrt-frr-algorithm] 1001 Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, 1002 "Algorithms for computing Maximally Redundant Trees for 1003 IP/LDP Fast- Reroute", 1004 draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in 1005 progress), October 2012. 1007 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1008 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1010 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1011 RFC 5714, January 2010. 1013 16.2. Informative References 1015 [EnyediThesis] 1016 Enyedi, G., "Novel Algorithms for IP Fast Reroute", 1017 Department of Telecommunications and Media Informatics, 1018 Budapest University of Technology and Economics Ph.D. 1019 Thesis, February 2011, 1020 . 1022 [I-D.atlas-rtgwg-mrt-mc-arch] 1023 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 1024 Envedi, "An Architecture for Multicast Protection Using 1025 Maximally Redundant Trees", 1026 draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress), 1027 March 2012. 1029 [I-D.ietf-mpls-ldp-multi-topology] 1030 Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP 1031 Extensions for Multi Topology Routing", 1032 draft-ietf-mpls-ldp-multi-topology-06 (work in progress), 1033 December 2012. 1035 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] 1036 Bryant, S., Previdi, S., and M. Shand, "A Framework for IP 1037 and MPLS Fast Reroute Using Not-via Addresses", 1038 draft-ietf-rtgwg-ipfrr-notvia-addresses-10 (work in 1039 progress), December 2012. 1041 [I-D.ietf-rtgwg-lfa-applicability] 1042 Filsfils, C. and P. Francois, "LFA applicability in SP 1043 networks", draft-ietf-rtgwg-lfa-applicability-06 (work in 1044 progress), January 2012. 1046 [I-D.ietf-rtgwg-ordered-fib] 1047 Shand, M., Bryant, S., Previdi, S., Filsfils, C., 1048 Francois, P., and O. Bonaventure, "Framework for Loop-free 1049 convergence using oFIB", draft-ietf-rtgwg-ordered-fib-09 1050 (work in progress), January 2013. 1052 [I-D.ietf-rtgwg-remote-lfa] 1053 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 1054 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 1055 (work in progress), December 2012. 1057 [LFARevisited] 1058 Retvari, G., Tapolcai, J., Enyedi, G., and A. Csaszar, "IP 1059 Fast ReRoute: Loop Free Alternates Revisited", Proceedings 1060 of IEEE INFOCOM , 2011, . 1063 [LightweightNotVia] 1064 Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP 1065 Fast ReRoute: Lightweight Not-Via without Additional 1066 Addresses", Proceedings of IEEE INFOCOM , 2009, 1067 . 1069 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 1070 Convergence", RFC 5715, January 2010. 1072 Authors' Addresses 1074 Alia Atlas (editor) 1075 Juniper Networks 1076 10 Technology Park Drive 1077 Westford, MA 01886 1078 USA 1080 Email: akatlas@juniper.net 1081 Robert Kebler 1082 Juniper Networks 1083 10 Technology Park Drive 1084 Westford, MA 01886 1085 USA 1087 Email: rkebler@juniper.net 1089 Gabor Sandor Enyedi 1090 Ericsson 1091 Konyves Kalman krt 11. 1092 Budapest 1097 1093 Hungary 1095 Email: Gabor.Sandor.Enyedi@ericsson.com 1097 Andras Csaszar 1098 Ericsson 1099 Konyves Kalman krt 11 1100 Budapest 1097 1101 Hungary 1103 Email: Andras.Csaszar@ericsson.com 1105 Jeff Tantsura 1106 Ericsson 1107 300 Holger Way 1108 San Jose, CA 95134 1109 USA 1111 Email: jeff.tantsura@ericsson.com 1113 Maciek Konstantynowicz 1114 Cisco Systems 1116 Email: maciek@bgp.nu 1117 Russ White 1118 Verisign 1119 12061 Bluemont Way 1120 Reston, VA 20190 1121 USA 1123 Email: riwhite@verisign.com 1125 Mike Shand 1127 Email: mike@mshand.org.uk