draft-ietf-pim-source-discovery-bsr-10.txt   draft-ietf-pim-source-discovery-bsr-11.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 29, 2018 M. Brig Expires: July 30, 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 25, 2018 January 26, 2018
PIM Flooding Mechanism and Source Discovery PIM Flooding Mechanism and Source Discovery
draft-ietf-pim-source-discovery-bsr-10 draft-ietf-pim-source-discovery-bsr-11
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 29, 2018. This Internet-Draft will expire on July 30, 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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 N messages per minute. This
document does not mandate how this should be implemented, but some document does not mandate how this should be implemented, but some
possible ways could be having a minimal time between each message, possible ways could be having a minimal time between each message,
counting the number of messages originated and resetting the count counting the number of messages originated and resetting the count
every minute, or using a leaky bucket algorithm. One benefit of every minute, or using a leaky bucket algorithm. One benefit of
using a leaky bucket algorithm is that it can handle bursts better. using a leaky bucket algorithm is that it can handle bursts better.
The default value of N is 6. The value MUST be configurable. The default value of N is 6. The value MUST be configurable.
Depending on the network one may want to use a low value allowing new Depending on the network, one may want to use a larger value of N to
information to be propagated, but with a large number of routers and favor propagation of new information, but with a large number of
many updates, the total number of messages might become too large and routers and many updates, the total number of messages might become
require too much processing. too large and require too much processing.
There MUST be a minimum of M milliseconds between each originated There MUST be a minimum of M milliseconds between each originated
message. The default value of M is 1000 (1 second). The value MUST message. The default value of M is 1000 (1 second). The value MUST
be configurable. 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
skipping to change at page 12, line 26 skipping to change at page 12, line 26
other values MAY be configured. A source MAY be announced with a other values MAY be configured. 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, so include information about other sources that were just detected,
sources that are scheduled for periodic announcement later, or other sources that are scheduled for periodic announcement later, or other
types of information. See Section 3.3 for details. Note that when a types of information. See Section 3.3 for details. Note that when a
new source is detected, one should trigger sending of a PFM message new source is detected, one should trigger sending of a PFM message
as soon as possible, while if a source becomes inactive, there is no as soon as possible, while if a source becomes inactive, there is no
reason to trigger a message. There is no urgency in removing state reason to trigger a message. There is no urgency in removing state
for inactive sources. for inactive sources. Note that the message timing requirements in
Section 3.3 apply. This means that one cannot always send a
triggered message immediately when a new source is detected. In
order to meet the timing requirements, sending of the message may
have to be delayed a small amount of time.
When a new PIM neighbor is detected, or an existing neighbor changes When a new PIM neighbor is detected, or an existing neighbor changes
Generation Identifier, an implementation MAY send a triggered PFM Generation Identifier, an implementation MAY send a triggered PFM
message containing GSH TLVs for any Source Group mappings it has message containing GSH TLVs for any Source Group mappings it has
learned by receiving PFM GSH TLVs as well as any active directly learned by receiving PFM GSH TLVs as well as any active directly
connected sources. See Section 3.3 for further details. connected sources. See Section 3.3 for further details.
4.3. Processing GSH TLVs 4.3. Processing GSH TLVs
A router that receives a PFM message containing GSH TLVs MUST parse A router that receives a PFM message containing GSH TLVs MUST parse
 End of changes. 7 change blocks. 
10 lines changed or deleted 14 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/