draft-ietf-pim-source-discovery-bsr-11.txt   draft-ietf-pim-source-discovery-bsr-12.txt 
Network Working Group IJ. Wijnands Network Working Group IJ. Wijnands
Internet-Draft S. Venaas Internet-Draft S. Venaas
Intended status: Experimental Cisco Systems, Inc. Intended status: Experimental Cisco Systems, Inc.
Expires: July 30, 2018 M. Brig Expires: August 4, 2018 M. Brig
Aegis BMD Program Office Aegis BMD Program Office
A. Jonasson A. Jonasson
Swedish Defence Material Administration (FMV) Swedish Defence Material Administration (FMV)
January 26, 2018 January 31, 2018
PIM Flooding Mechanism and Source Discovery PIM Flooding Mechanism and Source Discovery
draft-ietf-pim-source-discovery-bsr-11 draft-ietf-pim-source-discovery-bsr-12
Abstract Abstract
PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared
trees to forward multicast packets from new sources. Once last hop trees to forward multicast packets from new sources. Once last hop
routers receive packets from a new source, they may join the Shortest routers receive packets from a new source, they may join the Shortest
Path Tree for the source for optimal forwarding. This draft defines Path Tree for the source for optimal forwarding. This draft defines
a new mechanism that provides a way to support PIM-SM without the a new mechanism that provides a way to support PIM-SM without the
need for PIM registers, RPs or shared trees. Multicast source need for PIM registers, RPs or shared trees. Multicast source
information is flooded throughout the multicast domain using a new information is flooded throughout the multicast domain using a new
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2018. This Internet-Draft will expire on August 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and Deployment Experiences . . . . . . . . . . . . . 4 2. Testing and Deployment Experiences . . . . . . . . . . . . . 4
3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 4 3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5
3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6 3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7 3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7 3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9 3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9
3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9 3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10 3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10
4. Distributing Source Group Mappings . . . . . . . . . . . . . 10 4. Distributing Source Group Mappings . . . . . . . . . . . . . 10
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 10 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 10
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 11 4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 11
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 12 4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 13
4.4. The First Packets and Bursty Sources . . . . . . . . . . 13 4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14 4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
PIM Sparse-Mode (PIM-SM) uses a Rendezvous Point (RP) and shared PIM Sparse-Mode (PIM-SM) [RFC7761] uses a Rendezvous Point (RP) and
trees to forward multicast packets to Last Hop Routers (LHR). After shared trees to forward multicast packets to Last Hop Routers (LHR).
the first packet is received by a LHR, the source of the multicast After the first packet is received by a LHR, the source of the
stream is learned and the Shortest Path Tree (SPT) can be joined. multicast stream is learned and the Shortest Path Tree (SPT) can be
This draft defines a new mechanism that provides a way to support joined. This draft defines a new mechanism that provides a way to
PIM-SM without the need for PIM registers, RPs or shared trees. support PIM-SM without the need for PIM registers, RPs or shared
Multicast source information is flooded throughout the multicast trees. Multicast source information is flooded throughout the
domain using a new generic PIM flooding mechanism. By removing the multicast domain using a new generic PIM flooding mechanism. By
need for RPs and shared trees, the PIM-SM procedures are simplified, removing the need for RPs and shared trees, the PIM-SM procedures are
improving router operations, management and making the protocol more simplified, improving router operations, management and making the
robust. Also the data packets are only sent on the SPTs, providing protocol more robust. Also the data packets are only sent on the
optimal forwarding. SPTs, providing optimal forwarding.
This mechanism has some similarities to PIM Dense Mode (PIM-DM) with This mechanism has some similarities to PIM Dense Mode (PIM-DM) with
its State-Refresh signaling [RFC3973], except that there is no its State-Refresh signaling [RFC3973], except that there is no
initial flooding of data packets for new sources. It provides the initial flooding of data packets for new sources. It provides the
traffic efficiency of PIM-SM, while being as easy to deploy as PIM- traffic efficiency of PIM-SM, while being as easy to deploy as PIM-
DM. The downside is that it cannot provide forwarding of initial DM. The downside is that it cannot provide forwarding of initial
packets from a new source, see Section 4.4. PIM-DM is very different packets from a new source, see Section 4.4. PIM-DM is very different
from PIM-SM and not as mature, Experimental vs Internet Standard, and from PIM-SM and not as mature, Experimental vs Internet Standard, and
there are only a few implementations. The solution in this document there are only a few implementations. The solution in this document
consists of a lightweight source discovery mechanism on top of the consists of a lightweight source discovery mechanism on top of the
Source-Specific Multicast (SSM) parts of PIM-SM. It is feasable to Source-Specific Multicast (SSM) [RFC4607] parts of PIM-SM. It is
implement only a subset of PIM-SM to provide SSM support, and in feasable to implement only a subset of PIM-SM to provide SSM support,
addition implement the mechanism in this draft to offer a source and in addition implement the mechanism in this draft to offer a
discovery mechanism for applications that do not provide their own source discovery mechanism for applications that do not provide their
source discovery. own source discovery.
This document defines a generic flooding mechanism for distributing This document defines a generic flooding mechanism for distributing
information throughout a PIM domain. While the forwarding rules are information throughout a PIM domain. While the forwarding rules are
largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any largely similar to Bootstrap Router mechanism (BSR) [RFC5059], any
router can originate information, and it allows for flooding of any router can originate information, and it allows for flooding of any
kind of information. Each message contains one or more pieces of kind of information. Each message contains one or more pieces of
information encoded as TLVs (type, length and value). This document information encoded as TLVs (type, length and value). This document
defines one TLV used for distributing information about active defines one TLV used for distributing information about active
multicast sources. Other documents may define additional TLVs. multicast sources. Other documents may define additional TLVs.
skipping to change at page 3, line 43 skipping to change at page 3, line 44
mechanism is largely similar to BSR, there are some concerns about mechanism is largely similar to BSR, there are some concerns about
scale as there can be multiple routers distributing information, and scale as there can be multiple routers distributing information, and
potentially larger amount of data that needs to be processed and potentially larger amount of data that needs to be processed and
stored. Distributing knowledge of active sources in this way is new, stored. Distributing knowledge of active sources in this way is new,
and there are some concerns, mainly regarding potentially large and there are some concerns, mainly regarding potentially large
amounts of source states that need to be distributed. While there amounts of source states that need to be distributed. While there
has been some testing in the field, we need to learn more about the has been some testing in the field, we need to learn more about the
forwarding efficiency, both the amount of processing per router, and forwarding efficiency, both the amount of processing per router, and
propagation delay, and the amount of state that can be distributed. propagation delay, and the amount of state that can be distributed.
In particular, how many active sources one can support without In particular, how many active sources one can support without
consuming too many resources. There are also parameters that can be consuming too many resources. There are also parameters, see
tuned regarding how frequently information is distributed, and it is Section 5, that can be tuned regarding how frequently information is
not clear what parameters are useful for different types of networks. distributed, and it is not clear what parameters are useful for
different types of networks.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
RP: Rendezvous Point RP: Rendezvous Point
skipping to change at page 8, line 5 skipping to change at page 8, line 5
PFM message should be sent every time there is a new active source. PFM message should be sent every time there is a new active source.
However, the TLV also contains a holdtime and PFM messages need to be However, the TLV also contains a holdtime and PFM messages need to be
sent periodically. Generally speaking, a PFM message would typically sent periodically. Generally speaking, a PFM message would typically
be sent when there is a local state change, causing information to be be sent when there is a local state change, causing information to be
distributed with PFM to change. Also, some information may need to distributed with PFM to change. Also, some information may need to
be sent periodically. These messages are called triggered and be sent periodically. These messages are called triggered and
periodic messages, respectively. Each TLV definition will need to periodic messages, respectively. Each TLV definition will need to
define when a triggered PFM message needs to be originated, and also define when a triggered PFM message needs to be originated, and also
whether to send periodic messages, and how frequent. whether to send periodic messages, and how frequent.
A router MUST NOT originate more than N messages per minute. This A router MUST NOT originate more than Max_PFM_Message_Rate messages
document does not mandate how this should be implemented, but some per minute. This document does not mandate how this should be
possible ways could be having a minimal time between each message, implemented, but some possible ways could be having a minimal time
counting the number of messages originated and resetting the count between each message, counting the number of messages originated and
every minute, or using a leaky bucket algorithm. One benefit of resetting the count every minute, or using a leaky bucket algorithm.
using a leaky bucket algorithm is that it can handle bursts better. One benefit of using a leaky bucket algorithm is that it can handle
The default value of N is 6. The value MUST be configurable. bursts better. The default value of Max_PFM_Message_Rate is 6. The
Depending on the network, one may want to use a larger value of N to value MUST be configurable. Depending on the network, one may want
favor propagation of new information, but with a large number of to use a larger value of Max_PFM_Message_Rate to favor propagation of
routers and many updates, the total number of messages might become new information, but with a large number of routers and many updates,
too large and require too much processing. the total number of messages might become too large and require too
much processing.
There MUST be a minimum of M milliseconds between each originated There MUST be a minimum of Min_PFM_Message_Gap milliseconds between
message. The default value of M is 1000 (1 second). The value MUST each originated message. The default value of Min_PFM_Message_Gap is
be configurable. 1000 (1 second). The value MUST be configurable.
Unless otherwise specified by the TLV definitions, there is no Unless otherwise specified by the TLV definitions, there is no
relationship between different TLVs, and an implementation can choose relationship between different TLVs, and an implementation can choose
whether to combine TLVs in one message or across separate messages. whether to combine TLVs in one message or across separate messages.
It is RECOMMENDED to combine multiple TLVs in one message, to reduce It is RECOMMENDED to combine multiple TLVs in one message, to reduce
the number of messages, but it is also RECOMMENDED that the message the number of messages, but it is also RECOMMENDED that the message
is small enough to avoid fragmentation at the IP layer. When a is small enough to avoid fragmentation at the IP layer. When a
triggered PFM message needs to be sent due to a state change, a triggered PFM message needs to be sent due to a state change, a
router MAY send a message containing only the information that router MAY send a message containing only the information that
changed. If there are many changes occuring at about the same time, changed. If there are many changes occuring at about the same time,
skipping to change at page 12, line 8 skipping to change at page 12, line 8
TLVs. This is used to flood information about active multicast TLVs. This is used to flood information about active multicast
sources. Each FHR that is directly connected to an active multicast sources. Each FHR that is directly connected to an active multicast
source originates PFM messages containing GSH TLVs. How a multicast source originates PFM messages containing GSH TLVs. How a multicast
router discovers the source of the multicast packet and when it router discovers the source of the multicast packet and when it
considers itself the FHR follows the same procedures as the considers itself the FHR follows the same procedures as the
registering process described in [RFC7761]. When a FHR has decided registering process described in [RFC7761]. When a FHR has decided
that a register needs to be sent per [RFC7761], the SG is not that a register needs to be sent per [RFC7761], the SG is not
registered via the PIM-SM register procedures, but the SG mapping is registered via the PIM-SM register procedures, but the SG mapping is
included in an GSH TLV in a PFM message. Note, only the SG mapping included in an GSH TLV in a PFM message. Note, only the SG mapping
is distributed in the message, not the entire packet as would have is distributed in the message, not the entire packet as would have
been done with a PIM register. The PFM messages containing the GSH been done with a PIM register.
TLV are periodically sent for as long as the multicast source is
active, similar to how PIM registers are periodically sent. The The PFM messages containing the GSH TLV are sent periodically for as
default announcement period is 60 seconds, which means that as long long as the multicast source is active, similar to how PIM registers
as the source is active, it is included in a PFM message originated are sent periodically. This means that as long as the source is
every 60 seconds. The holdtime for the source MUST be either zero, active, it is included in a PFM message originated every
or larger than the announcement period. It is RECOMMENDED to be 3.5 Group_Source_Holdtime_Period seconds, within the general PFM timing
times the announcement period. The default holdtime is 210 seconds, requirements in Section 3.3. The default value of
other values MAY be configured. A source MAY be announced with a Group_Source_Holdtime_Period is 60. The value MUST be configurable.
The holdtime for the source MUST be set to either zero or
Group_Source_Holdtime_Holdtime. The value of the
Group_Source_Holdtime_Holdtime parameter MUST be larger than
Group_Source_Holdtime_Period. It is RECOMMENDED to be 3.5 times the
Group_Source_Holdtime_Period. The default value is 210 (seconds).
The value MUST be configurable. A source MAY be announced with a
holdtime of zero to indicate that the source is no longer active. holdtime of zero to indicate that the source is no longer active.
If an implementation supports originating GSH TLVs with different If an implementation supports originating GSH TLVs with different
holdtimes for different sources, it can if needed send multiple TLVs holdtimes for different sources, it can if needed send multiple TLVs
with the same group address. Due to the format, all the sources in with the same group address. Due to the format, all the sources in
the same TLV have the same holdtime. the same TLV have the same holdtime.
When a new source is detected, an implementation MAY send a PFM When a new source is detected, an implementation MAY send a PFM
message containing just that particular source. However, it MAY also message containing just that particular source. However, it MAY also
include information about other sources that were just detected, include information about other sources that were just detected,
skipping to change at page 14, line 34 skipping to change at page 14, line 43
The solution described in this document does not suffer from that The solution described in this document does not suffer from that
problem. If a network becomes partitioned and new sources become problem. If a network becomes partitioned and new sources become
active, the receivers in that partitioned will receive the SG active, the receivers in that partitioned will receive the SG
Mappings and join the source tree. Each partition works Mappings and join the source tree. Each partition works
independently of the other partition(s) and will continue to have independently of the other partition(s) and will continue to have
access to sources within that partition. Once the network has access to sources within that partition. Once the network has
healed, the periodic flooding of SG Mappings ensures that they are healed, the periodic flooding of SG Mappings ensures that they are
re-flooded into the other partition(s) and other receivers can join re-flooded into the other partition(s) and other receivers can join
to the newly learned sources. to the newly learned sources.
5. Security Considerations 5. Configurable Parameters
This document contains a number of configurable parameters. These
parameters are formally defined in Section 3.3 and Section 4.2, but
they are repeated here for ease of reference. These parameters all
have default values as noted below.
Max_PFM_Message_Rate: The maximum number of PFM messages a router is
allowed to originate per minute, see Section 3.3 for details. The
default value is 6.
Min_PFM_Message_Gap: The minimum amount of time between each PFM
message originated by a router in milliseconds, see Section 3.3
for details. The default is 1000.
Group_Source_Holdtime_Period: The announcement period for Group
Source Holdtime TLVs in seconds, see Section 4.2 for details. The
default value is 60.
Group_Source_Holdtime_Holdtime: The holdtime for Group Source
Holdtime TLVs in seconds, see Section 4.2 for details. The
default value is 210.
6. Security Considerations
When it comes to general PIM message security, see [RFC7761]. PFM When it comes to general PIM message security, see [RFC7761]. PFM
messages MUST only be accepted from a PIM neighbor, but as discussed messages MUST only be accepted from a PIM neighbor, but as discussed
in [RFC7761], any router can become a PIM neighbor by sending a Hello in [RFC7761], any router can become a PIM neighbor by sending a Hello
message. To control from where to accept PFM packets, one can limit message. To control from where to accept PFM packets, one can limit
which interfaces PIM is enabled, and also one can configure which interfaces PIM is enabled, and also one can configure
interfaces as administrative boundaries for PFM messages, see interfaces as administrative boundaries for PFM messages, see
Section 3.2. The implications of forged PFM messages depend on which Section 3.2. The implications of forged PFM messages depend on which
TLVs they contain. Documents defining new TLVs will need to discuss TLVs they contain. Documents defining new TLVs will need to discuss
the security considerations for the specific TLVs. In general the security considerations for the specific TLVs. In general
skipping to change at page 15, line 21 skipping to change at page 16, line 7
PIM-SM link-local messages can be authenticated using IPsec, see PIM-SM link-local messages can be authenticated using IPsec, see
[RFC7761] section 6.3 and [RFC5796]. Since PFM messages are link- [RFC7761] section 6.3 and [RFC5796]. Since PFM messages are link-
local messages sent hop by hop, a link-local PFM message can be local messages sent hop by hop, a link-local PFM message can be
authenticated using IPsec such that a router can verify that a authenticated using IPsec such that a router can verify that a
message was sent by a trusted neighbor and has not been modified. message was sent by a trusted neighbor and has not been modified.
However, to verify that a received message contains correct However, to verify that a received message contains correct
information announced by the originator specified in the message, one information announced by the originator specified in the message, one
will have to trust every router on the path from the originator and will have to trust every router on the path from the originator and
that each router has authenticated the received message. that each router has authenticated the received message.
6. IANA Considerations 7. IANA Considerations
This document requires the assignment of a new PIM message type for This document requires the assignment of a new PIM message type for
the PIM Flooding Mechanism (PFM) with the name "PIM Flooding the PIM Flooding Mechanism (PFM) with the name "PIM Flooding
Mechanism". IANA is also requested to create a registry for PFM TLVs Mechanism". IANA is also requested to create a registry for PFM TLVs
called "PIM Flooding Mechanism Message Types". Assignments for the called "PIM Flooding Mechanism Message Types". Assignments for the
registry are to be made according to the policy "IETF Review" as registry are to be made according to the policy "IETF Review" as
defined in [RFC8126]. The initial content of the registry should be: defined in [RFC8126]. The initial content of the registry should be:
Type Name Reference Type Name Reference
-------------------------------------------------- --------------------------------------------------
0 Reserved [this document] 0 Reserved [this document]
1 Source Group Holdtime [this document] 1 Source Group Holdtime [this document]
2-32767 Unassigned 2-32767 Unassigned
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Arjen Boers for contributing to the The authors would like to thank Arjen Boers for contributing to the
initial idea, and David Black, Stewart Bryant, Yiqun Cai, Toerless initial idea, and David Black, Stewart Bryant, Yiqun Cai,
Eckert, Dino Farinacci, Alvaro Retana and Liang Xia for their very Papadimitriou Dimitri, Toerless Eckert, Dino Farinacci, Alvaro Retana
helpful comments on the draft. and Liang Xia for their very helpful comments on the draft.
8. References 9. References
8.1. Normative References 9.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent "Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <https://www.rfc-editor.org/info/rfc5059>. 2008, <https://www.rfc-editor.org/info/rfc5059>.
skipping to change at page 16, line 27 skipping to change at page 17, line 16
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
8.2. Informative References 9.2. Informative References
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>. January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
 End of changes. 21 change blocks. 
66 lines changed or deleted 98 lines changed or added

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