draft-ietf-pim-source-discovery-bsr-00.txt   draft-ietf-pim-source-discovery-bsr-01.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: May 22, 2014 M. Brig Expires: January 4, 2015 M. Brig
Aegis BMD Program Office Aegis BMD Program Office
November 18, 2013 July 3, 2014
PIM flooding mechanism and source discovery PIM flooding mechanism and source discovery
draft-ietf-pim-source-discovery-bsr-00 draft-ietf-pim-source-discovery-bsr-01
Abstract Abstract
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to
forward multicast packets to Last Hop Routers (LHR). After the first forward multicast packets to Last Hop Routers (LHR). After the first
packet is received by the LHR, the source of the multicast stream is packet is received by the LHR, the source of the multicast stream is
learned and the Shortest Path Tree (SPT) can be joined. This draft learned and the Shortest Path Tree (SPT) can be joined. This draft
proposes a solution to support PIM Sparse Mode (SM) without the need proposes a solution to support PIM Sparse Mode (SM) without the need
for PIM registers, RPs or shared trees. Multicast source information for PIM registers, RPs or shared trees. Multicast source information
is flooded throughout the multicast domain using a new generic PIM is flooded throughout the multicast domain using a new generic PIM
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 22, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 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
skipping to change at page 2, line 33 skipping to change at page 2, line 28
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. A generic PIM flooding mechanism . . . . . . . . . . . . . . 3 2. A generic PIM flooding mechanism . . . . . . . . . . . . . . 3
2.1. PFP message format . . . . . . . . . . . . . . . . . . . 4 2.1. PFP message format . . . . . . . . . . . . . . . . . . . 4
3. Distributing Source to Group Mappings . . . . . . . . . . . . 5 3. Distributing Source to Group Mappings . . . . . . . . . . . . 5
3.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 5 3.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 5
4. Originating SG messages . . . . . . . . . . . . . . . . . . . 6 4. Originating SG messages . . . . . . . . . . . . . . . . . . . 6
5. Processing SG messages . . . . . . . . . . . . . . . . . . . 7 5. Processing SG messages . . . . . . . . . . . . . . . . . . . 7
6. The first packets and bursty sources . . . . . . . . . . . . 7 6. The first packets and bursty sources . . . . . . . . . . . . 7
7. Resiliency to network partitioning . . . . . . . . . . . . . 8 7. Resiliency to network partitioning . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to
skipping to change at page 3, line 23 skipping to change at page 3, line 21
1.2. Terminology 1.2. Terminology
RP: Rendezvous Point. RP: Rendezvous Point.
BSR: Bootstrap Router. BSR: Bootstrap Router.
RPF: Reverse Path Forwarding. RPF: Reverse Path Forwarding.
SPT: Shortest Path Tree. SPT: Shortest Path Tree.
FHR: First Hop Router, directly connected to the Source. FHR: First Hop Router, directly connected to the source.
LHR: Last Hop Router, directly connected to the receiver. LHR: Last Hop Router, directly connected to the receiver.
SG Mapping: Multicast source to group mapping. SG Mapping: Multicast source to group mapping.
SG Message: A PIM message containing SG Mappings. SG Message: A PIM message containing SG Mappings.
2. A generic PIM flooding mechanism 2. A generic PIM flooding mechanism
The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used
protocol for distributing dynamic Group to RP mappings in PIM. It is protocol for distributing dynamic Group to RP mappings in PIM. It is
responsible for flooding information about such mappings throughout a responsible for flooding information about such mappings throughout a
PIM domain, so that all routers in the domain can have the same PIM domain, so that all routers in the domain can have the same
information. BSR as defined, is only able to distribute Group to RP information. BSR as defined, is only able to distribute Group to RP
mappings. We are defining a more generic mechanism that can flood mappings. We are defining a more generic mechanism that can flood
any kind of information throughout a PIM domain. It is not any kind of information throughout a PIM domain. It is not
necessarily a domain though, it depends on administrative boundaries necessarily a domain though, it depends on the administrative
being configured. The forwarding rules are identical to BSR, except boundaries being configured. The forwarding rules are identical to
that there is no BSR election. The protocol includes an originator BSR, except that there is no BSR election and that one can control
whether routers should forward messages of unsupported types. For
some types of information it is quite useful that it can be
distributed without all routers having to support the particular
type, while there may also be types where it is necessary for every
single router to support it. The protocol includes an originator
address which is used for RPF checking to restrict the flooding, just address which is used for RPF checking to restrict the flooding, just
like BSR. Just like BSR it is also sent hop by hop. Note that there like BSR. Just like BSR it is also sent hop by hop. Note that there
is no built in election mechanism as in BSR, so there can be multiple is no built in election mechanism as in BSR, so there can be multiple
originators. It is still possible to add such an election mechanism originators. It is still possible to add such an election mechanism
if this protocol is used in scenarios where this is desirable. We on a type by type bases if this protocol is used in scenarios where
include a type field, which can allow boundaries to be defined, and this is desirable. We include a type field, which can allow
election to take place, independently per type. We call this boundaries to be defined, and election to take place, independently
protocol the PIM Flooding Protocol (PFP). per type. We call this protocol the PIM Flooding Protocol (PFP).
2.1. PFP message format 2.1. PFP message format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum | |PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) | | Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFP Type | Reserved |U| | PFP Type | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 1 | Length 1 | | Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 | | Value 1 |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| Type n | Length n | | Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n | | Value n |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version: Reserved, Checksum Described in [RFC4601]. PIM Version: Reserved, Checksum Described in [RFC4601].
Type: PIM Message Type. Value (pending IANA) for a PFP message. Type: PIM Message Type. Value (pending IANA) for a PFP message.
[N]o-Forward bit: When set, this bit means that the PFP message is [N]o-Forward bit: When set, this bit means that the PFP message is
not to be forwarded. not to be forwarded.
Originator Address: The address of the router that originated the Originator Address: The address of the router that originated the
message. This can be any address assigned to this router, but message. This can be any address assigned to this router, but
MUST be routable in the domain to allow successful forwarding MUST be routable in the domain to allow successful forwarding
(just like BSR address). The format for this address is given in (just like BSR address). The format for this address is given in
the Encoded-Unicast address in [RFC4601]. the Encoded-Unicast address in [RFC4601].
PFP Type: There may be different sub protocols or different uses PFP Type: There may be different sub protocols or different uses
for this generic protocol. The PFP Type specifies which sub for this generic protocol. The PFP Type specifies which sub
protocol it is used for. protocol it is used for.
[U]nknown-No-Forwarding bit: Some sub protocols may require each [U]nknown-No-Forwarding bit: Some sub protocols may require that
router to do some processing of the contents and not simply each router do some processing of the contents and not simply
forwarding. This bit controls how a router should treat an forwarding. This bit controls how a router should treat an
unknown PFP Type. When set, a router MUST NOT forward the message unknown PFP Type. When set, a router MUST NOT forward the message
when the PFP Type is unknown. When clear, a router MUST forward when the PFP Type is unknown. When clear, a router MUST forward
the message when possible. If the PFP Type is known, then the the message when possible. If the PFP Type is known, then the
specification of that type will specify how to handle the message, specification of that type will specify how to handle the message,
including whether it should be forwarded. including whether it should be forwarded.
Type 1..n: A message contains one or more TLVs, in this case n Type 1..n: A message contains one or more TLVs, in this case n
TLVs. The Type specifies what kind of information is in the TLVs. The Type specifies what kind of information is in the
Value. Note that the Type space is shared between all PFP. Not Value. Note that the Type space is shared between all PFP types.
all types make sense for all protocol types though. Not all types make sense for all PFP types though.
Length 1..n: The length of the the value field. Length 1..n: The length of the the value field.
Value 1..n: The value associated with the type and of the specified Value 1..n: The value associated with the type and of the specified
length. length.
3. Distributing Source to Group Mappings 3. Distributing Source to Group Mappings
We want to provide information about active multicast sources We want to provide information about active multicast sources
throughout a PIM domain by making use of the generic flooding throughout a PIM domain by making use of the generic flooding
mechanism defined in the previous section. We request PFP Type 0 to mechanism defined in the previous section. We request PFP Type 0 to
be assigned for this purpose. We call a message with PFP Type 0 an be assigned for this purpose. We call a message with PFP Type 0 an
SG Message. We also define a PFP TLV which we request to be type 0. SG Message. We also define a PFP TLV which we request to be type 0.
How this TLV is used with PFP Type 0 is defined in the next section. How this TLV is used with PFP Type 0 is defined in the next section.
Other PFP Types may specify the use of this TLV for other purposes. Other PFP Types may specify the use of this TLV for other purposes.
For PFP Type 0 the U-bit MUST NOT be set. This means that routers For PFP Type 0 the U-bit MUST NOT be set. This means that routers
not supporting PFP Type 0 would still forward the message. not supporting PFP Type 0 would still forward the message.
3.1. Group Source Holdtime TLV 3.1. Group Source Holdtime TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Length | | Type = 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime | | Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) | | Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) | | Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) | | Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: This TLV has type 0. Type: This TLV has type 0.
Length: The length of the value. Length: The length of the value.
Group Address: The group we are announcing sources for. The format Group Address: The group we are announcing sources for. The format
for this address is given in the Encoded-Group format in for this address is given in the Encoded-Group format in
[RFC4601]. [RFC4601].
Src Count: How many unicast encoded sources address encodings Src Count: How many unicast encoded sources address encodings
skipping to change at page 7, line 16 skipping to change at page 7, line 16
entire packet as would have been done with a PIM register. The entire packet as would have been done with a PIM register. The
router originating the SG messages includes one of its own addresses router originating the SG messages includes one of its own addresses
in the originator field. Note that this address must be routeable in the originator field. Note that this address must be routeable
due to RPF checking. The SG messages are periodically sent for as due to RPF checking. The SG messages are periodically sent for as
long as the multicast source is active, similar to how PIM registers long as the multicast source is active, similar to how PIM registers
are periodically sent. The default announcement period is 60 are periodically sent. The default announcement period is 60
seconds, which means that as long as the source is active, it is seconds, which means that as long as the source is active, it is
included in an SG message originated every 60 seconds. The holdtime included in an SG message originated every 60 seconds. The holdtime
for the source is by default 210 seconds. Other values can be for the source is by default 210 seconds. Other values can be
configured, but the holdtime must be larger than the announcement configured, but the holdtime must be larger than the announcement
period. period. It is RECOMMENDED to be 3.5 times the announcement period.
Note that as a special case a source MAY be announced with a holdtime
of 0 to indicate that the source is no longer active.
5. Processing SG messages 5. Processing SG messages
A router that receives an SG message should parse the message and A router that receives an SG message should parse the message and
store the SG mappings with a holdtimer started with the advertised store the SG mappings with a holdtimer started with the advertised
holdtime for that group. If there are directly connected receivers holdtime for that group. If there are directly connected receivers
for that group this router should send PIM (S,G) joins for all the SG for that group this router should send PIM (S,G) joins for all the SG
mappings advertised in the message. The SG mappings are kept alive mappings advertised in the message. The SG mappings are kept alive
for as long as the holdtimer for the source is running. Once the for as long as the holdtimer for the source is running. Once the
holdtimer expires a PIM (S,G) prune must be sent to remove itself holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to
from the tree. remove itself from the tree. Note that a holdtime of 0 has a special
meaning. It is to be treated as if the source just expired, causing
a prune to be sent and state to be removed. Source information MUST
not be removed due to it being omitted in a message. For instance,
if there are a large number of sources for a group, there may be
multiple SG messages for the same group, each message containing a
different list of sources.
6. The first packets and bursty sources 6. The first packets and bursty sources
The PIM register procedure is designed to deliver Multicast packets The PIM register procedure is designed to deliver Multicast packets
to the RP in the absence of a native SPT tree from the RP to the to the RP in the absence of a native SPT tree from the RP to the
source. The register packets received on the RP are decapsulated and source. The register packets received on the RP are decapsulated and
forwarded down the shared tree to the LHRs. As soon as an SPT tree forwarded down the shared tree to the LHRs. As soon as an SPT tree
is built, multicast packets would flow natively over the SPT to the is built, multicast packets would flow natively over the SPT to the
RP or LHR and the register process would stop. The PIM register RP or LHR and the register process would stop. The PIM register
process bridges the gap between how long it takes to build the SPT process ensures packet delivery until an SPT tree is in place
tree to the FHR. If the packets would not be unicast encapsulated to reaching the FHR. If the packets were not unicast encapsulated to
the RP they would be dropped by the FHR until the SPT is setup. This the RP they would be dropped by the FHR until the SPT is setup. This
functionality is important for applications where the initial functionality is important for applications where the initial
packet(s) must be received for the application to work correctly. packet(s) must be received for the application to work correctly.
Another reason would be for bursty sources. If the application sends Another reason would be for bursty sources. If the application sends
out a multicast packet every 4 minutes (or longer), the SPT is torn out a multicast packet every 4 minutes (or longer), the SPT is torn
down (typically after 3:30 minutes of inactivity) before the next down (typically after 3:30 minutes of inactivity) before the next
packet is forwarded down the tree. This will cause no multicast packet is forwarded down the tree. This will cause no multicast
packet to ever be forwarded. A well behaved application should packet to ever be forwarded. A well behaved application should
really be able to deal with packet loss since IP is a best effort really be able to deal with packet loss since IP is a best effort
based packet delivery system. But in reality this is not always the based packet delivery system. But in reality this is not always the
skipping to change at page 8, line 47 skipping to change at page 9, line 7
being a candidate RP. This would increase the operational complexity being a candidate RP. This would increase the operational complexity
of the network. of the network.
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. As soon as the network access to sources within that partition. As soon as the network
heals, the SG Mappings are re-flooded into the other partition(s) and heals, the SG Mappings are re-flooded into the other partition(s) and
other receives can join to the newly learned sources. other receivers can join to the newly learned sources.
8. Security Considerations 8. Security Considerations
The security considerations are no different from what is documented
in [RFC5059]. The security considerations are mainly similar to what is documented
in [RFC5059]. It may be a concern that rogue devices can inject
packets that are flooded throughout a domain. PFP packets SHOULD
only be accepted from a PIM neighbor. Deployments may use mechanisms
for authenticating PIM neighbors.
9. IANA considerations 9. IANA considerations
This document requires the assignment of a new PIM Protocol type for This document requires the assignment of a new PIM Protocol type for
the PIM Flooding Protocol (PFP). IANA also needs to create a the PIM Flooding Protocol (PFP). IANA is also requested to create a
registry for PFP Types with type 0 allocated to "Source-Group registry for PFP Types with type 0 allocated to "Source-Group
Message". IANA also needs to create a registry for PFP TLVs, with Message". IANA is also requested to create a registry for PFP TLVs,
type 0 allocated to the "Source Group Holdtime" TLV. The allocation with type 0 allocated to the "Source Group Holdtime" TLV. The
procedures are yet to be determined. allocation procedures are yet to be determined.
10. Acknowledgments 10. 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 Yiqun Cai for his comments on the draft. initial idea and Yiqun Cai for his comments on the draft.
11. References 11. References
11.1. Normative References 11.1. Normative References
 End of changes. 20 change blocks. 
71 lines changed or deleted 88 lines changed or added

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