idnits 2.17.1 draft-allan-pim-sr-mpls-multicast-framework-00.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 : ---------------------------------------------------------------------------- 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 (June 1, 2018) is 2128 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: 'MCAST-OPSF' is mentioned on line 593, but not defined == Unused Reference: 'MCAST-OSPF' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'SR-ARCH' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC7385' is defined on line 660, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group Dave Allan 2 Internet Draft Ericsson 3 Intended status: Standards Track Jeff Tantsura 4 Expires: December 1, 2018 Nuage 5 Ian Duncan 6 Ciena 7 June 1, 2018 9 A Framework for Computed Multicast Applied to SR-MPLS 10 draft-allan-pim-sr-mpls-multicast-framework-00 12 Abstract 14 This document describes a multicast solution for SR-MPLS. It is 15 consistent with the Segment Routing architecture in that an IGP is 16 augmented to distribute information in addition to the link state. In 17 this solution it is multicast group membership information sufficient 18 to synchronize state in a given network domain. Computation is 19 employed to determine the topology of any loosely specified multicast 20 distribution tree. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance 25 with the provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress". 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire in December 1st, 2018. 46 Copyright and License Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Authors......................................................3 64 1.2. Requirements Language........................................3 65 2. Changes from the last version..................................3 66 3. Conventions used in this document..............................4 67 3.1. Terminology..................................................4 68 4. Solution Overview..............................................5 69 4.1. Mapping source specific trees onto the segment routing 70 architecture......................................................6 71 4.2. Role of the Routing System...................................6 72 4.3. MDT Construction Requirements................................6 73 4.4. Simplification and Pruning - theory of operation.............7 74 5. Elements of Procedure..........................................7 75 5.1. Triggers for Computation.....................................7 76 5.2. FIB Determination............................................8 77 5.2.1. Information in the IGP.....................................8 78 5.2.2. Computation of individual segments.........................8 79 5.3. FIB Generation..............................................12 80 5.4. FIB installation............................................12 81 6. Related work..................................................13 82 6.1. IGP Extensions..............................................13 83 6.2. BGP Extensions..............................................13 84 7. Observations..................................................14 85 8. Acknowledgements..............................................14 86 9. Security Considerations.......................................14 87 10. IANA Considerations..........................................14 88 11. References...................................................14 89 11.1. Normative References.......................................14 90 11.2. Informative References.....................................15 91 12. Authors' Addresses...........................................15 93 1. Introduction 95 This memo describes a solution for multicast for SR-MPLS in which 96 source specific multicast distribution trees (MDTs) are computed from 97 information distributed via an IGP. Computation uses information in 98 the IGP to determine if a given node in the network has a role as a 99 root, a leaf or replication point in a given MDT. Unicast tunnels are 100 employed to interconnect the nodes determined to have a role. 101 Therefore multicast topological instructions only need be installed 102 in nodes that have one of these three roles to fully instantiate an 103 MDT. 104 Although this approach might appear to be computationally intensive, 105 a significant amount of computation can be avoided if and when the 106 computing agent determines that the node it is computing for has no 107 role in a given MDT. If there will be no need to install a multicast 108 topological instruction in that node for the given MDT, the computing 109 agent can abandon computation for the MDT and move on to other tasks, 110 such as converging other MDTs. This permits a computed approach to 111 multicast convergence to be computationally tractable. 112 This approach is proposed as a solution for networks for which an 113 implementation of an alternative data plane, such as BIER, offers 114 technical or economic challenges. 115 1.1. Authors 117 David Allan, Jeff Tantsura, Ian Duncan 119 1.2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC2119 [RFC2119]. 125 2. Changes from the last version 127 Clarification in motivation. 129 Editorial corrections and improvements. 131 Clarification of the description of upstream pruning in section 132 5.2.2 134 Alignment of terminology with current segment routing practice. 136 3. Conventions used in this document 138 3.1. Terminology 140 Candidate replication point (CRP) - is a node that potentially needs 141 to install a multicast topological instruction to replicate multicast 142 traffic as determined at an intermediate step in multicast segment 143 computation. It will either resolve to having no role or a role as a 144 replication point once multicast has converged. 146 Candidate role - refers to any potential combination of roles on a 147 given multicast segment as determined at some intermediate step in 148 MDT computation. For example, a node with a candidate role may be a 149 leaf and may also be a candidate replication point. 151 Computing agent- refers to the agent that will compute the FIB for 152 the MDTs in a given network on behalf of one node (distributed model) 153 or multiple nodes (SR controller(s) in a centralized model). 155 Downstream - refers to the direction along the shortest path to one 156 or more leaves for a given multicast distribution tree 158 Multicast convergence - is when all computation and multicast 159 topological instruction installation to ensure the FIB reflects the 160 multicast information in the IGP is complete. 162 MDT - multicast distribution tree. Is a tree composed of one or more 163 multicast segments. 165 Multicast segment - is a portion of the multicast tree where only the 166 root and the leaves have been specified, and computation based upon 167 the current state of the IGP database is employed to determine and 168 install the required topological instructions to implement the 169 segment. For SR-MPLS a multicast segment is implemented as a p2mp 170 LSP. A multicast segment is identified by a multicast SID. 172 Multicast SID - Is the topological instruction that is used to 173 implement a multicast segment. As per a unicast SR-MPLS segment, the 174 rightmost 20 bits of a multicast SID is encoded as a label. It is 175 drawn from the SRGB for the domain. 177 Pinned path - Is a unique shortest path extending from a leaf 178 upstream towards the root for a given multicast segment. Therefore, 179 it is a component of the multicast segment that it has been 180 determined must be there. It will not necessarily extend from the 181 leaf all the way to the root during intermediate computation steps. A 182 pinned path can result from pruning operations. 184 Role - refers specifically to a node that is either a root, a leaf, a 185 replication node, or a pinned waypoint for a given MDT. 187 Unicast convergence - is when all computation and topological 188 instruction installation to ensure the FIB reflects the unicast 189 information in the IGP is complete. 191 Upstream - refers to the direction along the shortest path to the 192 root of a given MDT. 194 4. Solution Overview 196 This memo describes a multicast architecture in which multicast 197 topological instructions are only installed in those nodes that have 198 roles as a root, a leaf, or a replication point for a given multicast 199 segment. The a-priori established mesh of unicast tunnels (using 200 node-SIDs) are used as interconnect between the nodes that have a 201 role in a given multicast SID. Hence on an outgoing interface where 202 the next node in that path of the MDT is not immediately adjacent, 203 the operation will typically be a CONTINUE of the multicast SID and a 204 PUSH of the node-SID. 206 A loosely specified MDT is composed of a single multicast segment and 207 the routing of the MDT is delegated entirely to computation driven by 208 information in the IGP database. 210 Explicitly routed MDTs are expressed as a tree of concatenated 211 multicast segments where both the leaves of each segment and the 212 waypoints coupling a given segment to the upstream and/or downstream 213 segment(s) is specified in information flooded in the IGP by the 214 overall root of the MDT. The segments themselves will be computed as 215 per a loosely specified MDT. 217 A PE acting as an overall root for a given tree is expected to be 218 configured by the operator as to where to source multicast traffic 219 from, be it an attachment circuit, interworking function for client 220 technology or other. Similarly, a leaf for a given tree is expected 221 to be configured by the operator as to the disposition of received 222 multicast traffic. 224 A computed segment is guaranteed to be loop free in a stable fault 225 free system. A concatenation of segments to construct an MDT will 226 similarly be loop free as any collision of segments can be 227 disambiguated in the data plane via the SIDs. 229 This architecture significantly reduces the number of multicast 230 topological instructions that needs to be installed in the data plane 231 to support multicast. This also means that the impact of many 232 failures in the network on multicast traffic distribution will be 233 recovered by unicast local repair or unicast convergence with 234 subsequent multicast convergence acting in the role of network re- 235 optimization (as opposed to restoration). 237 4.1. Mapping source specific trees onto the segment routing architecture 239 A computed source specific tree for a given multicast group 240 corresponds to one or more multicast segments in the SR architecture. 241 Each multicast segment is assigned a SID, typically by management 242 configuration of the node that will be the overall root for the 243 source specific tree. The root node then uses the IGP to advertise 244 this information to all nodes in the IGP area/domain. 246 A multicast group is implemented as the set of source specific trees 247 from all nodes that have registered transmit interest to all nodes 248 that have registered receive interest in a multicast group. 250 4.2. Role of the Routing System 252 The role of the IGP is to communicate topology information, multicast 253 capability and associated algorithm, multicast registrations, unicast 254 to node-SID bindings, multicast to SID bindings and waypoints in 255 multi-segment MDTs. No changes to topology or unicast to node-SID 256 binding advertisements are proposed by this memo. 258 The multicast registrations/bindings will be in the form of source, 259 group, transmit/receive interest and the SID to use for the source 260 specific multicast tree. Registrations are originated by any node 261 that has send or receive interest in a given multicast group. Nodes 262 will use the combination of topology and multicast registrations to 263 determine the nodes that have a role in each source specific tree and 264 the SID information to then derive the required FIB state. 266 4.3. MDT Construction Requirements 268 A multicast segment in an MDT is constructed such that between any 269 pair of nodes that have a role in the segment and are connected by a 270 unicast tunnel, there is not another node on the shortest path 271 between the two with a role in that segment. This ensures that copies 272 of a packet forwarded by a multicast segment will traverse a link 273 only once in a stable system and avoids the potential scenario 274 whereby a packet needs to be replicated twice on a given interface. 276 Note that this can be satisfied by a minimum cost shortest path tree, 277 but this is not an absolute requirement. The pruning rules specified 278 in this memo will meet this requirement without necessarily producing 279 an absolute minimum cost multicast segment (or incurring the 280 associated computational cost). 282 4.4. Simplification and Pruning - theory of operation 284 The role of nodes in a given multicast segment is determined by first 285 producing an inclusive shortest path tree with all possible paths 286 between the root and leaves, and then applying a set of 287 simplification and pruning rules repeatedly until either an acyclic 288 tree is produced, or no further prunes are possible. 290 For the majority of multicast segments these rules will 291 authoritatively produce a minimum cost tree. For those segments that 292 are not able to be authoritatively resolved, there is a set of 293 pruning operations applied that are not guaranteed to produce a tree 294 that meets the requirements of 3.3, therefore these trees require 295 auditing and potential correction according to a further set of 296 agreed rules. This avoids the necessity and computational overhead of 297 an exhaustive search of the solution space. 299 A computing agent during computation of a segment may conclude that 300 none of the nodes that it is computing on behalf of will have a role 301 at any point in the computation process and abandon computation of 302 that segment. 304 5. Elements of Procedure 306 5.1. Triggers for Computation 308 MDT computation is triggered by changes to the IGP database. These 309 are in the form of either changes in registered multicast group 310 interest, addition or removal of a multi-segment MDT descriptor, or 311 topology changes. 313 A change in registered interest for a group will require re- 314 computation of all MDTs that implement the multicast group. 316 A topology change will require the computation of some number of 317 multicast segments, the actual number will depend on the 318 implementation of tree computation but at a minimum will be all trees 319 for which there is not an optimal shortest path solution as a result 320 of the topology change. 322 5.2. FIB Determination 324 5.2.1. Information in the IGP 326 Group membership information for a multicast segment is obtained from 327 the IGP. This is true for single segment MDTs as well as multi- 328 segment MDTs. Included in the multi-segment MDT specification is the 329 waypoint nodes in MDT and the upstream and downstream SIDs. The 330 specified node is expected to cross connect the SIDs to join the 331 segments together acting in the role of leaf for the upstream segment 332 and root for the downstream segment. 334 When a waypoint in an MDT descriptor does not exist in the IGP, the 335 assumption is that the node identified by the waypoint SID has 336 failed. The response of the other nodes in the system in FIB 337 determination is to add the leaves of the downstream segment to the 338 upstream segment. 340 An example of this would be consider a node "x", and another node 341 "y". At some point in time, "x" advertises a tree that identifies "y" 342 as a waypoint that cross connects upstream SID "a" to downstream SID 343 "b". At some later point node "y" fails. The other nodes in the 344 network will compute segment "a" as if it included all leaves and 345 waypoints in segment "b". All apriori state installed for segment "b" 346 would be removed as the failure of "y" has required "b" to be 347 subsumed by "a". 349 5.2.2. Computation of individual segments 351 FIB generation for a multicast segment is the result of computation, 352 ultimately as applied to all source specific trees in the network. 353 All computing agents in a given network computing a tree for a given 354 multicast segment must implement a common algorithm for tree 355 generation, as all MUST agree on the solution. 357 One algorithm is as follows: 359 All possible shortest paths to the set of leaves for the MDT is 360 determined. Then simplification and pruning rules are repeatedly 361 applied until no further prunes are possible or the MDT is determined 362 to be resolved. 364 The distinction between simplification rules and pruning rules is the 365 former will not change the candidate role of a node with respect to 366 the MDT under consideration and therefore can be performed in any 367 order, while the latter will affect candidate node roles and must be 368 performed in an agreed order between all participating computing 369 agents. 371 The philosophy of the application of these rules could be expressed 372 as "simplify as much as possible, and prune that which cannot be". 373 The rules are: 375 1) Simplification: Eliminate any links and nodes not on a potential 376 shortest path from the root to the leaves for the MDT under 377 consideration. 379 2) Simplification: Replace any nodes that do not have a potential 380 role in the MDT with links. 382 This will be nodes that are not a leaf, a root or a candidate 383 replication point. For example: 385 Root---------A----------B 387 B is a leaf. A is not but is in a potential shortest path from root 388 to B. However, A will have no role in the MDT that serves B as it 389 provides simple transit therefore is replaced with a direct 390 connection between the root and B. 392 Root--------------------B 394 Note that such simplification also needs to avoid the creation of 395 duplicate parallel links. For example: 397 /----------A----------\ 399 Root B 401 \----------C----------/ 403 Where A and C have no role and the cost root-A-B = cost root-C-B, 404 they can be replaced with a single link from Root to B. 406 3) Simplification: Eliminate of fewer hop paths 408 When for a given set of leaves, a node has multiple downstream 409 links that converge on a common downstream point, and that set of 410 leaves is only a subset of the leaves reachable on one or more of 411 the links, any link that only serves that subset of leaves can be 412 eliminated. 414 For example: 416 --A---------------------------B 418 \ / 420 -----------C----------- 422 \ 424 ----D 426 Link AB is cost 2, link AC and CB are cost 1 (cost of link CD does 427 not affect the example). 429 B and D are leaves of a root upstream of A. From A, link AB can 430 reach leaf B. Path AC can reach leaf B and D. In this case path A-B 431 can be eliminated from consideration. The set of leaves reachable 432 via link A-B is a subset of that reachable by A-C, and the paths 433 from A that serves that subset converges at B. 435 4) Prune: upstream links. 437 The normal procedure is to determine the best-closest upstream 438 leaf or pinned path and then compare all upstream adjacencies with 439 that metric. Note that the best-closest upstream leaf or pinned 440 path may not be directly connected to the node under 441 consideration. Where there is more than one equally close upstream 442 leaf or pinned path, the highest ranked is selected with the 443 ranking being that a leaf is ranked superior to a pinned path, and 444 the lowest unicast SID is selected when the leaf/pinned path 445 ranking is equal. 447 Then examine each of the remaining upstream adjacencies: 449 a. If the upstream adjacency extends closer to the root than 450 the closest leaf or pinned path, then that adjacency can be 451 pruned. 453 b. If the upstream adjacency extends the same distance towards 454 the root as the best-closest adjacency, then it can be 455 eliminated as it has already been ranked lower than the best- 456 closest adjacency. Note that this would include non-leaf and 457 non-pinned path candidate replication points. 459 c. If the upstream adjacency is a candidate replication point 460 closer than the best-closest leaf or pinned path, then it is 461 left alone. 463 When for a given node all possible upstream adjacencies that can be 464 pruned have been identified, each is removed, and any simplifications 465 that can be performed as a result of the prune are performed. This is 466 the equivalent of a localized check for 2 and 3 above and is then 467 performed iteratively in response to changes to the graph as a result 468 of pruning. 470 The procedure is to implement all simplifications of type 1, 2 and 3 471 above, then loop on type 4 prunes until such time as the MDT is fully 472 resolved from the point of view of the node under consideration, or 473 no further prunes are possible. Step 4 is required to be performed in 474 a specific order if there is more than one computing agent generating 475 topological instructions for a given multicast segment. This memo 476 suggests that the nodes are processed according to a ranking of nodes 477 from closest to the root to the farthest, and from lowest unicast SID 478 to the highest within a given distance from the root. 480 At the end of pruning and simplification, either: 482 1) The node whom the computing agent is computing for has no role in 483 the multicast segment under consideration 485 2) A unique shortest path to the root has been determined for all 486 leaves in the multicast segment that are downstream of the node 487 under consideration (also termed as a pinned path from the root 488 to every leaf). 490 3) A unique shortest path to the root has not been determined for all 491 leaves downstream of the node under consideration in the 492 multicast segment. 494 If 1 or 2 then the multicast segment is considered to be resolved, 495 and for 2, the computation can progress directly to the topological 496 instruction generation step for that segment. 498 If 3 (not all downstream leaves have a unique shortest path), 499 additional pruning steps are applied. These steps are NOT guaranteed 500 to produce a lowest cost tree, and therefore require an additional 501 audit and possible modification to ensure when forwarding a maximum 502 of one copy of a packet will traverse an interface. 504 For segments not authoritatively resolved by the above rules, a prune 505 that will not authoritatively result in a minimum cost tree is 506 applied. For the purpose of interoperability, the following rule is 507 applied: A computing agent will select the closest node to the root 508 with a candidate role that does not have a unique shortest path to 509 the root. Where more than one such node exists, the one with the 510 lowest node-SID is selected. For that node, the best upstream link is 511 selected and all other upstream links pruned. The best upstream link 512 is defined as the link with the closest node with a candidate role 513 that potentially serves the highest number of leaves. Where there is 514 a tie, once again the node with the lowest unicast SID is selected. 516 Once the links have been pruned, rules 2 through 4 are repeatedly 517 applied until either the tree is fully resolved, or again no further 518 prunes are possible, in which case the next closest remaining 519 unresolved node has the same prune applied. 521 For all segments not resolved by the initial prune rules, they are 522 audited to ensure all nodes that have a role in the tree do not have 523 a node with a role between them and their upstream node on the tree. 524 If they do, the old upstream adjacency is removed, and the superior 525 one added. 527 5.3. FIB Generation 529 The topology components that remain at the end of the simplification 530 and pruning operations will reflect all nodes that have a role in a 531 given multicast segment plus the necessary tunnels (as all 532 intervening multi-path scenarios will have been simplified away). 533 From this the topological instructions to put in the FIB can be 534 generated: 536 All nodes that have a role in a given multicast segment and have 537 nodes upstream in the segment will need to accept the multicast SID 538 for the MDT from at minimum, all upstream interfaces. 540 All nodes that have a role in a given segment and have nodes 541 immediately downstream in the segment will need to replicate packets 542 simply labelled with the multicast SID onto those interfaces. 544 All nodes that have a role in a given segment and have nodes 545 reachable via a tunnel downstream set the FIB to push the tunnel 546 unicast SID for the downstream node onto any replicated copies of a 547 received packet, and identify the set of interfaces on the shortest 548 path for the tunnel SID. 550 5.4. FIB installation 552 FIB installation needs to acknowledge two aspects of the hybrid 553 tunnel and role model of multicast tree construction. The first is 554 that because of the sparse state model simple tree adds, moves, and 555 changes may require the installation of topological instructions 556 where they did not previously exist, and such changes may impact 557 existing services. The second is that it is possible to retain the 558 knowledge to prioritize computation of those trees impacted the 559 failure of a node with a role. 561 To address this in the distributed model, there are three stages of 562 topological instruction installation for multicast convergence: 564 1) Immediate: 566 a. Installation of topological instructions for multicast 567 segments impacted by the failure of a node in the network, 568 and installation of topological instructions for segments in 569 nodes that have not previously had a role in the given 570 segment. 572 b. Installation of topological instructions for waypoints in 573 multi-segment MDTs. 575 2) After T1: Update topological instructions for nodes that both had 576 and have a role in a given multicast segment. 578 3) After T2: Removal of topological instructions for nodes that 579 transition from having a role to not having a role for a given 580 multicast segment. 582 T1 and T2 are network wide configurable values. 584 When an SR-Controller is used, it is only necessary to properly 585 sequence the installation of state. This also suggests that when 586 there is more than one SR-Controller, the division of responsibility 587 should be on the basis of MDT ownership. 589 6. Related work 591 6.1. IGP Extensions 593 The required IGP changes are documented in [MCAST-ISIS] and [MCAST- 594 OPSF]. 596 6.2. BGP Extensions 598 This memo will require the specification of a new PMSI Tunnel 599 Attribute (SPRING P2MP tunnel, tentatively 0x0c) to order to 600 integrate into the multicast framework documented in RFC 6514 602 7. Observations 604 This technique is not confined to SR-MPLS: 606 - with the provision of a global label space (to be employed as per a 607 multicast SID), an MPLS-LDP network would also provide the requisite 608 mesh of unicast tunnels and be capable of implementing this approach 609 to multicast. 611 - It is also possible to envision an SRv6 implementation but would 612 require the ability to rewrite the SRH at each hop. 614 This memo focuses on an implementation based upon nodes that are IGP 615 speakers and converge independently so is written in a form that 616 assumes a node, computing agent and IGP speaker are one in the same. 617 It should be observed that the relative frugality of data plane state 618 would suggest that separation of computation from nodes in the data 619 plane combined with management or "software defined networking" based 620 population of the multicast FIB entries may also be useful modes of 621 network operation. 623 8. Acknowledgements 625 Thanks to Uma Chunduri for his detailed review and suggestions. 627 9. Security Considerations 629 For a future version of this document. 631 10. IANA Considerations 633 This document requires the allocation of a PMSI tunnel type to 634 identify a SPRING P2MP tunnel type from the P-Multicast Service 635 Interface Tunnel (PMSI Tunnel) Tunnel Types registry. 637 11. References 639 11.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 11.2. Informative References 646 [MCAST-ISIS] Allan et.al., "IS-IS extensions for Computed Multicast 647 applied to MPLS based Segment Routing", IETF work in progress, 648 draft-allan-isis-spring-multicast-00, July 2016 650 [MCAST-OSPF] Allan et.al., "OSPF extensions for Computed Multicast 651 applied to MPLS based Segment Routing", IETF work in progress, 652 draft-allan-ospf-spring-multicast-00, July 2016 654 [SR-ARCH] Filsfils et.al., "Segment Routing Architecture", IETF work in 655 progress, draft-ietf-spring-segment-routing-15, January 2018 657 [RFC6514] Aggarwal et.al., "BGP Encodings and Procedures for Multicast 658 in MPLS/BGP IP VPNs", IETF RFC 6514, February 2012 660 [RFC7385] Andersson & Swallow "IANA Registry for P-Multicast Service 661 Interface (PMSI) Tunnel Type Code Points", IETF RFC 7385, 662 October 2014 664 12. Authors' Addresses 666 Dave Allan (editor) 667 Ericsson 668 2455 Augustine Drive 669 Santa Clara 95054 670 USA 671 Email: david.i.allan@ericsson.com 673 Jeff Tantsura 674 Email: jefftant.ietf@gmail.com 676 Ian Duncan 677 Ciena 678 iduncan@ciena.com 679 5050 Innovation Drive 680 Kanata, ON K2K 0J2