< draft-allan-spring-mpls-multicast-framework-01.txt   draft-allan-spring-mpls-multicast-framework-02.txt >
SPRING Working Group Dave Allan SPRING Working Group Dave Allan
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Standards Track Jeff Tantsura Intended status: Standards Track Jeff Tantsura
Expires: December 2016 Expires: March 2017
June 2016 September 2016
A Framework for Computed Multicast applied to MPLS based Segment A Framework for Computed Multicast applied to MPLS based Segment
Routing Routing
draft-allan-spring-mpls-multicast-framework-01 draft-allan-spring-mpls-multicast-framework-02
Abstract Abstract
This document describes a multicast solution for Segment Routing with This document describes a multicast solution for Segment Routing with
MPLS data plane. It is consistent with the Segment Routing MPLS data plane. It is consistent with the Segment Routing
architecture in that an IGP is augmented to distribute information in architecture in that an IGP is augmented to distribute information in
addition to the link state. In this solution it is multicast group addition to the link state. In this solution it is multicast group
membership information sufficient to synchronize state in a given membership information sufficient to synchronize state in a given
network domain. Computation is employed to determine the topology of network domain. Computation is employed to determine the topology of
any loosely specified multicast distribution tree. any loosely specified multicast distribution tree.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress". in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2016. This Internet-Draft will expire on March 2017.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Authors......................................................3 1.1. Authors......................................................3
1.2. Requirements Language........................................3 1.2. Requirements Language........................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
2.1. Terminology..................................................3 2.1. Terminology..................................................3
3. Solution Overview..............................................4 3. Solution Overview..............................................4
3.1. Mapping source specific trees onto the segment routing 3.1. Mapping source specific trees onto the segment routing
architecture......................................................5 architecture......................................................5
3.2. Role of the Routing System...................................5 3.2. Role of the Routing System...................................6
3.3. MDT Construction Requirements................................6 3.3. MDT Construction Requirements................................6
3.4. Pruning - theory of operation................................6 3.4. Pruning - theory of operation................................6
4. Elements of Procedure..........................................7 4. Elements of Procedure..........................................7
4.1. Triggers for Computation.....................................7 4.1. Triggers for Computation.....................................7
4.2. FIB Determination............................................7 4.2. FIB Determination............................................7
4.2.1. Information in the IGP.....................................7 4.2.1. Information in the IGP.....................................7
4.2.2. Computation of individual segments.........................8 4.2.2. Computation of individual segments.........................8
4.3. FIB Generation..............................................10 4.3. FIB Generation..............................................11
4.4. FIB installation............................................11 4.4. FIB installation............................................11
5. Related work..................................................11 5. Related work..................................................12
5.1. IGP Extensions..............................................11 5.1. IGP Extensions..............................................12
5.2. BGP Extensions..............................................11 5.2. BGP Extensions..............................................12
6. Observations..................................................12 6. Observations..................................................12
7. Acknowledgements..............................................12 7. Acknowledgements..............................................13
8. Security Considerations.......................................12 8. Security Considerations.......................................13
9. IANA Considerations...........................................12 9. IANA Considerations...........................................13
10. References...................................................12 10. References...................................................13
10.1. Normative References.......................................12 10.1. Normative References.......................................13
10.2. Informative References.....................................12 10.2. Informative References.....................................13
11. Authors' Addresses...........................................13 11. Authors' Addresses...........................................14
1. Introduction 1. Introduction
This memo describes a solution for multicast for Segment Routing with This memo describes a solution for multicast for Segment Routing with
MPLS data plane in which source specific multicast distribution trees MPLS data plane in which source specific multicast distribution trees
(MDTs) are computed from information distributed via an IGP. (MDTs) are computed from information distributed via an IGP.
Computation can use information in the IGP to determine if a given Computation can use information in the IGP to determine if a given
node in the network has a role as a root, leaf or replication point node in the network has a role as a root, leaf or replication point
in a given MDT. Unicast tunnels are employed to interconnect the in a given MDT. Unicast tunnels are employed to interconnect the
nodes determined to have a role. Therefore state only need be nodes determined to have a role. Therefore state only need be
installed in nodes that have one of these three roles to fully installed in nodes that have one of these three roles to fully
instantiate an MDT. instantiate an MDT.
Although this approach is computationally intensive, a significant Although this approach is computationally intensive, a significant
amount of computation can be avoided when the computing agent amount of computation can be avoided when the computing agent
determines that the node it is computing for has no role in a given determines that the node it is computing for has no role in a given
MDT. This permits a computed approach to multicast convergence to be MDT. This permits a computed approach to multicast convergence to be
computationally tractable. computationally tractable.
1.1. Authors 1.1. Authors
Dave Allan, Jeff Tantsura David Allan, Jeff Tantsura
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
2. Conventions used in this document 2. Changes from the last version
2.1. Terminology Clarifications in the pruning and simplification algorithm
Candidate replication point - is a node that potentially needs to 3. Conventions used in this document
install state to replicate multicast traffic as determined at an
3.1. Terminology
Candidate replication point (CRP) - is a node that potentially needs
to install state to replicate multicast traffic as determined at an
intermediate step in multicast segment computation. It will either intermediate step in multicast segment computation. It will either
resolve to having no role or a role as a replication point once resolve to having no role or a role as a replication point once
multicast has converged. multicast has converged.
Candidate role - refers to any potential combination of roles on a Candidate role - refers to any potential combination of roles on a
given multicast segment as determined at some intermediate step in given multicast segment as determined at some intermediate step in
MDT computation. For example, a node with a candidate role may be a MDT computation. For example, a node with a candidate role may be a
leaf and may be a candidate replication point. leaf and may be a candidate replication point.
Downstream - refers to the direction along the shortest path to one Downstream - refers to the direction along the shortest path to one
skipping to change at page 4, line 40 skipping to change at page 4, line 44
Role - refers specifically to a node that is either a root, a leaf, a Role - refers specifically to a node that is either a root, a leaf, a
replication node, or a pinned waypoint for a given MDT. replication node, or a pinned waypoint for a given MDT.
Unicast convergence - is when all computation and state installation Unicast convergence - is when all computation and state installation
to ensure the FIB reflects the unicast information in the IGP is to ensure the FIB reflects the unicast information in the IGP is
complete. complete.
Upstream - refers to the direction along the shortest path to the Upstream - refers to the direction along the shortest path to the
root of a given MDT. root of a given MDT.
3. Solution Overview 4. Solution Overview
This memo describes a multicast architecture in which multicast state This memo describes a multicast architecture in which multicast state
is only installed in those nodes that have roles as a root, leaves, is only installed in those nodes that have roles as a root, leaves,
and replication points for a given multicast segment. The a-priori and replication points for a given multicast segment. The a-priori
established segment routing unicast tunnels are used as interconnect established segment routing unicast tunnels are used as interconnect
between the nodes that have a role in a given multicast SID. between the nodes that have a role in a given multicast SID.
A loosely specified MDT is composed of a single multicast segment and A loosely specified MDT is composed of a single multicast segment and
the routing of the MDT is delegated entirely to computation driven by the routing of the MDT is delegated entirely to computation driven by
information in the IGP database. information in the IGP database.
skipping to change at page 5, line 32 skipping to change at page 5, line 36
data plane via the SIDs. data plane via the SIDs.
This architecture significantly reduces the amount of state that This architecture significantly reduces the amount of state that
needs to be installed in the data plane to support multicast. This needs to be installed in the data plane to support multicast. This
also means that the impact of many failures in the network on also means that the impact of many failures in the network on
multicast traffic distribution will be recovered by unicast local multicast traffic distribution will be recovered by unicast local
repair or unicast convergence with subsequent multicast convergence repair or unicast convergence with subsequent multicast convergence
acting in the role of network re-optimization (as opposed to acting in the role of network re-optimization (as opposed to
restoration). restoration).
3.1. Mapping source specific trees onto the segment routing architecture 4.1. Mapping source specific trees onto the segment routing architecture
A computed source specific tree for a given multicast group A computed source specific tree for a given multicast group
corresponds to one or more multicast segments in the SR architecture. corresponds to one or more multicast segments in the SR architecture.
Each multicast segment is assigned a SID, typically by management Each multicast segment is assigned a SID, typically by management
configuration of the node that will be the overall root for the configuration of the node that will be the overall root for the
source specific tree. The root node then uses the IGP to advertise source specific tree. The root node then uses the IGP to advertise
this information to all nodes in the IGP area/domain. this information to all nodes in the IGP area/domain.
A multicast group is implemented as the set of source specific trees A multicast group is implemented as the set of source specific trees
from all nodes that have registered transmit interest to all nodes from all nodes that have registered transmit interest to all nodes
that have registered receive interest in a multicast group. that have registered receive interest in a multicast group.
3.2. Role of the Routing System 4.2. Role of the Routing System
The role of the IGP is to communicate topology information, multicast The role of the IGP is to communicate topology information, multicast
capability and associated algorithm, multicast registrations, unicast capability and associated algorithm, multicast registrations, unicast
to SID bindings, multicast to SID bindings and waypoints in multi- to SID bindings, multicast to SID bindings and waypoints in multi-
segment MDTs. No changes to topology or unicast to SID binding segment MDTs. No changes to topology or unicast to SID binding
advertisements are proposed by this memo. advertisements are proposed by this memo.
The multicast registrations/bindings will be in the form of source, The multicast registrations/bindings will be in the form of source,
group, transmit/receive interest and the SID to use for the source group, transmit/receive interest and the SID to use for the source
specific multicast tree. Registrations are originated by any node specific multicast tree. Registrations are originated by any node
that has send or receive interest in a given multicast group. Nodes that has send or receive interest in a given multicast group. Nodes
will use the combination of topology and multicast registrations to will use the combination of topology and multicast registrations to
determine the nodes that have a role in each source specific tree and determine the nodes that have a role in each source specific tree and
the SID information to then derive the required FIB state. the SID information to then derive the required FIB state.
3.3. MDT Construction Requirements 4.3. MDT Construction Requirements
A multicast segment in an MDT is constructed such that between any A multicast segment in an MDT is constructed such that between any
pair of nodes that have a role in the segment and are connected by a pair of nodes that have a role in the segment and are connected by a
unicast tunnel, there is not another node on the shortest path unicast tunnel, there is not another node on the shortest path
between the two with a role in that segment. This ensures that copies between the two with a role in that segment. This ensures that copies
of a packet forwarded by an multicast segment will traverse a link of a packet forwarded by an multicast segment will traverse a link
only once in a stable system. only once in a stable system.
Note that this can be satisfied by a minimum cost shortest path tree, Note that this can be satisfied by a minimum cost shortest path tree,
but is not an absolute requirement. The pruning rules specified in but is not an absolute requirement. The pruning rules specified in
this memo will meet this requirement without necessarily producing this memo will meet this requirement without necessarily producing
absolutely minimum cost multicast segment (or incurring the absolutely minimum cost multicast segment (or incurring the
associated computational cost). associated computational cost).
3.4. Pruning - theory of operation 4.4. Pruning - theory of operation
The role of nodes in a given multicast segment is determined by first The role of nodes in a given multicast segment is determined by first
producing an inclusive shortest path tree with all possible paths producing an inclusive shortest path tree with all possible paths
between the root and leaves, and then applying a set of pruning rules between the root and leaves, and then applying a set of pruning rules
repeatedly until an acyclic tree is produced or no further prunes are repeatedly until an acyclic tree is produced or no further prunes are
possible. possible.
For the majority of multicast segments these rules will For the majority of multicast segments these rules will
authoritatively produce a minimum cost tree. For those segments that authoritatively produce a minimum cost tree. For those segments that
have not yet been authoritatively resolved, there is a set of pruning have not yet been authoritatively resolved, there is a set of pruning
operations applied that are not guaranteed to produce a tree that operations applied that are not guaranteed to produce a tree that
meets the requirements of 3.3, therefore these trees require auditing meets the requirements of 3.3, therefore these trees require auditing
and potential correction according to a further set of agreed rules. and potential correction according to a further set of agreed rules.
This avoids the necessity of an exhaustive search of the solution This avoids the necessity of an exhaustive search of the solution
space. space.
A node during computation of a segment may conclude that it will A node during computation of a segment may conclude that it will
absolutely not have a role at any of numerous points in the absolutely not have a role at any of numerous points in the
computation process and abandon computation of that segment. computation process and abandon computation of that segment.
4. Elements of Procedure 5. Elements of Procedure
4.1. Triggers for Computation 5.1. Triggers for Computation
MDT computation is triggered by changes to the IGP database. These MDT computation is triggered by changes to the IGP database. These
are in the form of either changes in registered multicast group are in the form of either changes in registered multicast group
interest, addition or removal of a multi-segment MDT descriptor, or interest, addition or removal of a multi-segment MDT descriptor, or
topology changes. topology changes.
A change in registered interest for a group will require re- A change in registered interest for a group will require re-
computation of all MDTs that implement the multicast group. computation of all MDTs that implement the multicast group.
A topology change will require the computation of some number of A topology change will require the computation of some number of
multicast segments, the actual number will depend on the multicast segments, the actual number will depend on the
implementation of tree computation but at a minimum will be all trees implementation of tree computation but at a minimum will be all trees
for which there is not an optimal shortest path solution as a result for which there is not an optimal shortest path solution as a result
of the topology change. of the topology change.
4.2. FIB Determination 5.2. FIB Determination
4.2.1. Information in the IGP 5.2.1. Information in the IGP
Group membership information for a multicast segment is obtained from Group membership information for a multicast segment is obtained from
the IGP. This is true for single segment MDTs as well as multi- the IGP. This is true for single segment MDTs as well as multi-
segment MDTs. Included in the multi-segment MDT specification is the segment MDTs. Included in the multi-segment MDT specification is the
waypoint nodes in MDT and the upstream and downstream SIDs. The waypoint nodes in MDT and the upstream and downstream SIDs. The
specified node is expected to cross connect the SIDs to join the specified node is expected to cross connect the SIDs to join the
segments together acting in the role of leaf for the upstream segment segments together acting in the role of leaf for the upstream segment
and root for the downstream segment. and root for the downstream segment.
When a waypoint in an MDT descriptor does not exist in the IGP, the When a waypoint in an MDT descriptor does not exist in the IGP, the
skipping to change at page 8, line 5 skipping to change at page 8, line 7
An example of this would be consider a node "x", and another node An example of this would be consider a node "x", and another node
"y". At some point in time, "x" advertises a tree that identifies "y" "y". At some point in time, "x" advertises a tree that identifies "y"
as a waypoint that cross connects upstream SID "a" to downstream SID as a waypoint that cross connects upstream SID "a" to downstream SID
"b". At some later point node "y" fails. The other nodes in the "b". At some later point node "y" fails. The other nodes in the
network will compute segment "a" as if it included all leaves and network will compute segment "a" as if it included all leaves and
waypoints in segment "b". All apriori state installed for segment "b" waypoints in segment "b". All apriori state installed for segment "b"
would be removed as the failure of "y" has required "b" to be would be removed as the failure of "y" has required "b" to be
subsumed by "a". subsumed by "a".
4.2.2. Computation of individual segments 5.2.2. Computation of individual segments
FIB generation for a multicast segment is the result of computation, FIB generation for a multicast segment is the result of computation,
ultimately as applied to all source specific trees in the network. ultimately as applied to all source specific trees in the network.
All computing nodes implement a common algorithm for tree generation, All computing nodes implement a common algorithm for tree generation,
as all MUST agree on the solution. as all MUST agree on the solution.
One algorithm is as follows: One algorithm is as follows:
All possible shortest paths to the set of leaves for the MDT is All possible shortest paths to the set of leaves for the MDT is
determined. Then pruning rules are repeatedly applied until no determined. Then pruning rules are repeatedly applied until no
skipping to change at page 9, line 34 skipping to change at page 9, line 37
Link AB is cost 2, link AC and CB are cost 1 (cost of link CD does Link AB is cost 2, link AC and CB are cost 1 (cost of link CD does
not affect the example). not affect the example).
B and D are leaves of a root upstream of A. From A, link AB can B and D are leaves of a root upstream of A. From A, link AB can
reach leaf B. Path AC can reach leaf B and D. In this case path A-B reach leaf B. Path AC can reach leaf B and D. In this case path A-B
can be pruned from consideration. The set of leaves reachable via can be pruned from consideration. The set of leaves reachable via
link A-B is a subset of that reachable by A-C, and the paths from A link A-B is a subset of that reachable by A-C, and the paths from A
that serves that subset converges at B. that serves that subset converges at B.
4) Prune via the elimination of upstream links where the nearest 4) Prune upstream links.
reachable leaf is further than the closest leaf or pinned path,
and that path does not have a candidate replication point closer
than the closet leaf or pinned path, as the resulting tree will
require the shortest path to transit the closest upstream leaf or
pinned path.
For each upstream link for each leaf in a segment the nearest leaf The normal procedure is to determine the closest upstream leaf or
or pinned path is determined. Those links for which the nearest pinned path and then compare all upstream adjacencies with that
leaf is further upstream than the closest leaf are pruned. metric
a. If the upstream adjacency extends closer to the root than
the closest leaf or pinned path, then that adjacency can be
pruned.
b. If the upstream adjacency extends the same distance towards
the root then
i. If it is to a non-leaf or pinned path candidate
replication point, it can be pruned
ii. If it is to a pinned path, where there are equal upstream
adjacencies that terminate on leaves, it can be pruned
(considered inferior).
iii. If there is more than one "equal" upstream adjacency,
that is all terminate on nodes that are on pinned paths,
or all terminate on nodes that are leaves, than one is
selected. This is via the lowest node ID.
c. If the upstream adjacency is a candidate replication point
closer than the closest leaf, and upstream from it is a node
that is a leaf or pinned path equidistant with the closest
leaf, then all adjacencies that extend to leaves ranked lower
than the leaf or pinned path behind the CRP may be pruned.
Note that an upstream adjacency that has a CRP closer than
the closest leaf or pinned path cannot be pruned.
d. When for a given node all possible upstream adjacencies that
can be pruned have been identified, each is removed, and any
simplifications that can be performed as a result of the
prune are performed. This is the equivalent of a localized
check for 2 and 3 above and is then performed iteratively in
response to changes to the graph as a result of pruning.
The procedure is to implement 1, 2 and 3 above, then loop on 4 until
such time as the MDT is fully resolved, or no further prunes are
possible. Step 4 is performed in a specific order. The nodes are
processed according to a ranking from closest to the root to the
farthest, and from lowest node ID to the highest within a given
distance from the root.
If, at the end of pruning and simplification, all leaves in a If, at the end of pruning and simplification, all leaves in a
multicast segment have a unique shortest path to the root, the tree multicast segment have a unique shortest path to the root, the tree
is considered resolved, and the computation can progress directly to is considered resolved, and the computation can progress directly to
the FIB generation step. the FIB generation step.
If not all leaves have a unique shortest path, additional pruning If not all leaves have a unique shortest path, additional pruning
steps are applied. These steps are NOT guaranteed to produce a lowest steps are applied. These steps are NOT guaranteed to produce a lowest
cost tree, and therefore require an additional audit and possible cost tree, and therefore require an additional audit and possible
modification to ensure when forwarding a maximum of one copy of a modification to ensure when forwarding a maximum of one copy of a
skipping to change at page 10, line 31 skipping to change at page 11, line 22
applied until either the tree is fully resolved, or again no further applied until either the tree is fully resolved, or again no further
prunes are possible, in which case the next closest remaining prunes are possible, in which case the next closest remaining
unresolved node has the same prune applied. unresolved node has the same prune applied.
For all segments not resolved by the initial prune rules, they are For all segments not resolved by the initial prune rules, they are
audited to ensure all nodes that have a role in the tree do not have audited to ensure all nodes that have a role in the tree do not have
a node with a role between them and their upstream node on the tree. a node with a role between them and their upstream node on the tree.
If they do, the old upstream adjacency is removed, and the superior If they do, the old upstream adjacency is removed, and the superior
one added. one added.
4.3. FIB Generation 5.3. FIB Generation
The topology components that remain at the end of the pruning The topology components that remain at the end of the pruning
operation will reflect all nodes that have a role in a given operation will reflect all nodes that have a role in a given
multicast segment plus the necessary tunnels (as all intervening multicast segment plus the necessary tunnels (as all intervening
multi-path scenarios will have been simplified away). From this the multi-path scenarios will have been simplified away). From this the
FIB can be generated: FIB can be generated:
All nodes that have a role in a given multicast segment and have All nodes that have a role in a given multicast segment and have
nodes upstream in the segment will need to accept the SID for the MDT nodes upstream in the segment will need to accept the SID for the MDT
from at minimum, all upstream interfaces. from at minimum, all upstream interfaces.
skipping to change at page 11, line 7 skipping to change at page 11, line 44
All nodes that have a role in a given segment and have nodes All nodes that have a role in a given segment and have nodes
immediately downstream in the segment will need to replicate packets immediately downstream in the segment will need to replicate packets
simply labelled with the multicast SID onto those interfaces. simply labelled with the multicast SID onto those interfaces.
All nodes that have a role in a given segment and have nodes All nodes that have a role in a given segment and have nodes
reachable via a tunnel downstream set the FIB to push the tunnel reachable via a tunnel downstream set the FIB to push the tunnel
unicast SID for the downstream node onto any replicated copies of a unicast SID for the downstream node onto any replicated copies of a
received packet, and identify the set of interfaces on the shortest received packet, and identify the set of interfaces on the shortest
path for the tunnel SID. path for the tunnel SID.
4.4. FIB installation 5.4. FIB installation
FIB installation needs to acknowledge two aspects of the hybrid FIB installation needs to acknowledge two aspects of the hybrid
tunnel and role model of multicast tree construction. The first is tunnel and role model of multicast tree construction. The first is
that because of the sparse state model simple tree adds, moves, and that because of the sparse state model simple tree adds, moves, and
changes may require the installation of state where it did not changes may require the installation of state where it did not
previously exist, and such changes may impact existing services. The previously exist, and such changes may impact existing services. The
second is that it is possible to retain the knowledge to prioritize second is that it is possible to retain the knowledge to prioritize
computation of those trees impacted the failure of a node with a computation of those trees impacted the failure of a node with a
role. role.
skipping to change at page 11, line 38 skipping to change at page 12, line 28
b. Installation of state for waypoints in multi-segment MDTs. b. Installation of state for waypoints in multi-segment MDTs.
2) After T1: Update state for nodes that both had and have a role in 2) After T1: Update state for nodes that both had and have a role in
a given multicast segment. a given multicast segment.
3) After T2: Removal of state for nodes that transition from having a 3) After T2: Removal of state for nodes that transition from having a
role to not having a role for a given multicast segment. role to not having a role for a given multicast segment.
T1 and T2 are network wide configurable values. T1 and T2 are network wide configurable values.
5. Related work 6. Related work
5.1. IGP Extensions 6.1. IGP Extensions
The required IGP changes are documented in [MCAST-ISIS] and [MCAST- The required IGP changes are documented in [MCAST-ISIS] and [MCAST-
OPSF]. OPSF].
5.2. BGP Extensions 6.2. BGP Extensions
This memo will require the specification of a new PMSI Tunnel This memo will require the specification of a new PMSI Tunnel
Attribute (SPRING P2MP tunnel, tentatively 0x09) to order to Attribute (SPRING P2MP tunnel, tentatively 0x09) to order to
integrate into the multicast framework documented in RFC 6514 integrate into the multicast framework documented in RFC 6514
6. Observations 7. Observations
This technique is not confined to segment routing, and with the This technique is not confined to segment routing, and with the
provision of a global label space (to be employed as per a multicast provision of a global label space (to be employed as per a multicast
SID), an MPLS-LDP network would also provide the requisite mesh of SID), an MPLS-LDP network would also provide the requisite mesh of
unicast tunnels and be capable of implementing this approach to unicast tunnels and be capable of implementing this approach to
multicast. multicast.
This memo focuses on an implementation based upon nodes that are IGP This memo focuses on an implementation based upon nodes that are IGP
speakers and converge independently so is written in a form that speakers and converge independently so is written in a form that
assumes a node, computing node and IGP speaker are one in the same. assumes a node, computing node and IGP speaker are one in the same.
It should be observed that the relative frugality of data plane state It should be observed that the relative frugality of data plane state
would suggest that separation of computation from nodes in the data would suggest that separation of computation from nodes in the data
plane combined with management or "software defined networking" based plane combined with management or "software defined networking" based
population of the multicast FIB entries may also be useful modes of population of the multicast FIB entries may also be useful modes of
network operation. network operation.
7. Acknowledgements 8. Acknowledgements
Thanks to Uma Chunduri for his detailed review and suggestions. Thanks to Uma Chunduri for his detailed review and suggestions.
8. Security Considerations 9. Security Considerations
For a future version of this document. For a future version of this document.
9. IANA Considerations 10. IANA Considerations
This document requires the allocation of a PMSI tunnel type to This document requires the allocation of a PMSI tunnel type to
identify a SPRING P2MP tunnel type from the P-Multicast Service identify a SPRING P2MP tunnel type from the P-Multicast Service
Interface Tunnel (PMSI Tunnel) Tunnel Types registry. Interface Tunnel (PMSI Tunnel) Tunnel Types registry.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 11.2. Informative References
[MCAST-ISIS] Allan et.al., "IS-IS extensions for Computed Multicast [MCAST-ISIS] Allan et.al., "IS-IS extensions for Computed Multicast
applied to MPLS based Segment Routing", IETF work in progress, applied to MPLS based Segment Routing", IETF work in progress,
draft-allan-isis-spring-multicast-00, July 2016 draft-allan-isis-spring-multicast-00, July 2016
[MCAST-OSPF] Allan et.al., "OSPF extensions for Computed Multicast [MCAST-OSPF] Allan et.al., "OSPF extensions for Computed Multicast
applied to MPLS based Segment Routing", IETF work in progress, applied to MPLS based Segment Routing", IETF work in progress,
draft-allan-ospf-spring-multicast-00, July 2016 draft-allan-ospf-spring-multicast-00, July 2016
[RFC6514] Aggarwal et.al., "BGP Encodings and Procedures for Multicast [RFC6514] Aggarwal et.al., "BGP Encodings and Procedures for Multicast
in MPLS/BGP IP VPNs", IETF RFC 6514, February 2012 in MPLS/BGP IP VPNs", IETF RFC 6514, February 2012
[RFC7385] Andersson & Swallow "IANA Registry for P-Multicast Service [RFC7385] Andersson & Swallow "IANA Registry for P-Multicast Service
Interface (PMSI) Tunnel Type Code Points", IETF RFC 7385, Interface (PMSI) Tunnel Type Code Points", IETF RFC 7385,
October 2014 October 2014
11. Authors' Addresses 12. Authors' Addresses
Dave Allan (editor) Dave Allan (editor)
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
Jeff Tantsura Jeff Tantsura
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 37 change blocks. 
53 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/