draft-ietf-pim-dr-improvement-07.txt   draft-ietf-pim-dr-improvement-08.txt 
PIM WG Zheng. Zhang PIM WG Zheng. Zhang
Internet-Draft Fangwei. Hu Internet-Draft ZTE Corporation
Intended status: Standards Track Benchong. Xu Intended status: Standards Track Fangwei. Hu
Expires: July 21, 2019 ZTE Corporation Expires: February 16, 2020 Individual
Benchong. Xu
ZTE Corporation
Mankamana. Mishra Mankamana. Mishra
Cisco Systems Cisco Systems
January 17, 2019 August 15, 2019
PIM DR Improvement PIM DR Improvement
draft-ietf-pim-dr-improvement-07.txt draft-ietf-pim-dr-improvement-08.txt
Abstract Abstract
Protocol Independent Multicast - Sparse Mode (PIM-SM) is widely Protocol Independent Multicast - Sparse Mode (PIM-SM) is widely
deployed multicast protocol. PIM protocol is defined in [RFC7761]. deployed multicast protocol. As deployment for PIM protocol is
As deployment for PIM protocol is growing day by day, user expects growing day by day, user expects lower traffic loss and faster
lower traffic loss and faster convergence in case of any network convergence in case of any network failure. This document provides
failure. This document provides an extension to the existing an extension to the existing protocol which would improve the
protocol which would improve the stability of the PIM protocol with stability of the PIM protocol with respect to traffic loss and
respect to traffic loss and convergence time when the PIM DR is down. convergence time when the PIM DR role changes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 21, 2019. This Internet-Draft will expire on February 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 2, line 26 skipping to change at page 2, line 28
3.1. DR Address Option format . . . . . . . . . . . . . . . . 4 3.1. DR Address Option format . . . . . . . . . . . . . . . . 4
3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4 3.2. BDR Address Option format . . . . . . . . . . . . . . . . 4
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 5
4.1. Deployment Choice . . . . . . . . . . . . . . . . . . . . 6 4.1. Deployment Choice . . . . . . . . . . . . . . . . . . . . 6
4.2. Election Algorithm . . . . . . . . . . . . . . . . . . . 6 4.2. Election Algorithm . . . . . . . . . . . . . . . . . . . 6
4.3. Sending Hello Messages . . . . . . . . . . . . . . . . . 7 4.3. Sending Hello Messages . . . . . . . . . . . . . . . . . 7
4.4. Receiving Hello Messages . . . . . . . . . . . . . . . . 8 4.4. Receiving Hello Messages . . . . . . . . . . . . . . . . 8
4.5. The treatment . . . . . . . . . . . . . . . . . . . . . . 9 4.5. The treatment . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Sender side . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Sender side . . . . . . . . . . . . . . . . . . . . . . . 10
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Deployment suggestion . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Multicast technology is used widely. Many modern technologies, such Multicast technology is used widely. Many modern technologies, such
as IPTV, Net-Meeting, use PIM-SM to facilitate multicast service. as IPTV, Net-Meeting, use PIM-SM to facilitate multicast service.
There are many events that will influence the quality of multicast There are many events that will influence the quality of multicast
services. Like the change of unicast routes, the change of the PIM- services. Like the change of unicast routes, the change of the PIM-
SM DR may cause the loss of multicast packets too. SM DR may cause the loss of multicast packets too.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
------- ------- ------- -------
| DR | | DR |
| | | |
------- ------- ------- -------
| SW |-----------------------------| SW | | SW |-----------------------------| SW |
------- ------- ------- -------
| | | |
Figure 1: An example of multicast network Figure 1: An example of multicast network
For example, there are two routers on one LAN. Two SWs (Layer 2 For example, there are two routers on one LAN. Two SWs (Layer 2
switchers) provide shared-media LAN connection. RouterA is elected switches) provide shared-media LAN connection. RouterA is elected as
as DR. When RouterA goes down, the multicast packets are discarded DR. When RouterA goes down, the multicast packets are discarded
until the RouterB is elected to DR and RouterB imports the multicast until the RouterB is elected to DR and RouterB imports the multicast
flows successfully. flows successfully.
We suppose that there is only a RouterA in the LAN at first in We suppose that there is only a RouterA in the LAN at first in
Figure 1. RouterA is the DR which is responsible for forwarding Figure 1. RouterA is the DR which is responsible for forwarding
multicast flows. When RouterB connects to the LAN, RouterB will be multicast flows. When RouterB connects to the LAN, RouterB will be
elected as DR because of its higher priority. RouterA will stop elected as DR because of its higher priority. RouterA will stop
forwarding multicast packets. The multicast flows will not recover forwarding multicast packets. The multicast flows will not recover
until RouterB pulls the multicast flows after it is elected to DR. until RouterB pulls the multicast flows after it is elected to DR.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
Backup Designated Router (BDR): Like DR (Designated Router), a BDR Backup Designated Router (BDR): Like DR (Designated Router), a BDR
which acts on behalf of directly connected hosts in a shared-media which acts on behalf of directly connected hosts in a shared-media
LAN. But BDR must not forward the flows when DR works normally. LAN. But BDR must not forward the flows when DR works normally.
When DR goes down, the BDR will forward multicast flows immediately. When DR goes down, the BDR will forward multicast flows immediately.
A single BDR MUST be elected per interface like the DR. A single BDR MUST be elected per interface like the DR.
Designed Router Other (DROther): A router which is neither DR nor Designated Router Other (DROther): A router which is neither DR nor
BDR. BDR.
3. PIM hello message format 3. PIM hello message format
The PIM hello message format is defined in [RFC7761]. In this The PIM hello message format is defined in [RFC7761]. In this
document, we define two new option values which are including Type, document, we define two new option values which are including Type,
Length, and Value. Length, and Value.
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
skipping to change at page 5, line 26 skipping to change at page 5, line 26
value of DR is filled. If the value of DR is filled with IP address value of DR is filled. If the value of DR is filled with IP address
of the router which is sending hello messages, the router will store of the router which is sending hello messages, the router will store
the IP address as the DR address of this interface. the IP address as the DR address of this interface.
Then the new router compares the priority and IP address itself to Then the new router compares the priority and IP address itself to
the stored information of DR and BDR according to the algorithm of the stored information of DR and BDR according to the algorithm of
[RFC7761]. If the new router notices that it is better to be DR than [RFC7761]. If the new router notices that it is better to be DR than
the current DR or BDR, the new router will make itself the BDR, and the current DR or BDR, the new router will make itself the BDR, and
send new hello messages with its IP address as BDR and current DR. send new hello messages with its IP address as BDR and current DR.
If the router notices that the current DR has the highest priority in If the router notices that the current DR has the highest priority in
the shared-media LAN, but the current BDR is set to 0x00000000 if the shared-media LAN, but the current BDR is set to 0.0.0.0 if IPv4
IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses addresses are in use or 0:0:0:0:0:0:0:0/128 if IPv6 addresses are in
are in use in the received hello messages (To simplify, we use 0x0 in use in the received hello messages (To simplify, we use 0x0 in
abbreviation in following parts of the draft), or the current BDR is abbreviation in following parts of the draft), or the current BDR is
not better than the new router, the new router will elect itself to not better than the new router, the new router will elect itself to
BDR. If the router notices that it is not better to be DR than BDR. If the router notices that it is not better to be DR than
current DR and BDR, the router will follow the current DR and BDR. current DR and BDR, the router will follow the current DR and BDR.
When the new router becomes the new BDR, the router will join the When the new router becomes the new BDR, the router will join the
current multicast groups, and import multicast flows from upstream current multicast groups, and import multicast flows from upstream
routers. But the BDR must not forward the multicast flows to avoid routers. But the BDR must not forward the multicast flows to avoid
the duplicate multicast packets in the shared-media LAN. The new the duplicate multicast packets in the shared-media LAN. The new
router will monitor the DR. The method that BDR monitors the DR may router will monitor the DR. The method that BDR monitors the DR may
be BFD (Bidirectional Forwarding Detection) [RFC5880] technology or be Bidirectional Forwarding Detection (BFD) for Multi-point Networks
other ways that can be used to detect link/node failure quickly. and Protocol Independent Multicast [I-D.ietf-pim-bfd-p2mp-use-case]
When the DR becomes unavailable because of the down or other reasons, technology, BFD (Bidirectional Forwarding Detection) [RFC5880]
the BDR will forward multicast flows immediately. technology, or other ways that can be used to detect link/node
failure quickly. When the DR becomes unavailable because of the down
or other reasons, the BDR will forward multicast flows immediately.
Asynchronous mode defined in BFD [RFC5880] is suggested to be used BFD for PIM function defined in [I-D.ietf-pim-bfd-p2mp-use-case], or
asynchronous mode defined in BFD [RFC5880] are suggested to be used
for the DR failure detection. BDR monitors DR after the BFD session for the DR failure detection. BDR monitors DR after the BFD session
between DR and BDR is established. For example, an aggressive BFD between DR and BDR is established. For example, an aggressive BFD
session that achieves a detection time of 50 milliseconds, by using a session that achieves a detection time of 300 milliseconds, by using
transmit interval of 16.7 milliseconds and a detect multiplier of 3. a transmit interval of 100 milliseconds and a detect multiplier of 3.
So BDR can replace DR to forward flows when DR goes down within 100 So BDR can replace DR to forward flows when DR goes down within sub
milliseconds. The other BFD modes can also be used to monitor the second. The other BFD modes can also be used to monitor the failure
failure of DR, the network administrator should choose the most of DR, the network administrator should choose the most suitable
suitable function. function.
4.1. Deployment Choice 4.1. Deployment Choice
DR / BDR election SHOULD be handled in two ways. Selection of which DR / BDR election SHOULD be handled in two ways. Selection of which
procedure to use would be totally dependent on deployment scenario. procedure to use would be totally dependent on deployment scenario.
1. The algorithm defined in [RFC7761] should be used if it is ok to 1. The algorithm defined in [RFC7761] should be used if it is ok to
adopt with new DR as and when they are available, and the loss caused adopt with new DR as and when they are available, and the loss caused
by DR changing is acceptable. by DR changing is acceptable.
2. If the deployment requirement is to have minium packets loss when 2. If the deployment requirement is to have minimum packets loss
DR changing, the mechanism defined in this draft should be used. when DR changing, the mechanism defined in this draft should be used.
That is, if the new router notices that it is better to be DR than That is, if the new router notices that it is better to be DR than
the current DR or BDR, the new router will make itself the BDR, and the current DR or BDR, the new router will make itself the BDR, and
send new hello message with its IP address as BDR and current DR. send new hello message with its IP address as BDR and current DR.
According to section 4.9.2 defined in [RFC7761], the device receives According to section 4.9.2 defined in [RFC7761], the device receives
unknown options Hello packet will ignore it. So the new extension unknown options Hello packet will ignore it. So the new extension
defined in this draft will not influence the stability of neighbor. defined in this draft will not influence the stability of neighbor.
But if the router which has the ability defined in this draft But if the router which has the ability defined in this draft
receives non-DR/BDR capable Hello messages defined in [RFC7761], the receives non-DR/BDR capable Hello messages defined in [RFC7761], the
router MAY stop sending DR/BDR capable Hello messages in the LAN and router MAY stop sending DR/BDR capable Hello messages in the LAN and
skipping to change at page 6, line 41 skipping to change at page 6, line 44
The DR and BDR election is according to the rules defined below, the The DR and BDR election is according to the rules defined below, the
algorithm is similar to the DR election defined in [RFC2328]. algorithm is similar to the DR election defined in [RFC2328].
(1) Note the current values for the network's Designated Router and (1) Note the current values for the network's Designated Router and
Backup Designated Router. This is used later for comparison Backup Designated Router. This is used later for comparison
purposes. purposes.
(2) Calculate the new Backup Designated Router for the network as (2) Calculate the new Backup Designated Router for the network as
follows. The router that has not declared itself to be Designated follows. The router that has not declared itself to be Designated
Router is eligible to become Backup Designated Router. The one which Router is eligible to become Backup Designated Router. The one which
has the highest priority will be chosen to be Backup Designed Router. has the highest priority will be chosen to be Backup Designated
In case of a tie, the one having the highest primary address is Router. In case of a tie, the one having the highest primary address
chosen. is chosen.
(3) Calculate the new Designated Router for the network as follows. (3) Calculate the new Designated Router for the network as follows.
If one or more of the routers have declared themselves Designated If one or more of the routers have declared themselves Designated
Router (i.e., they are currently listing themselves as Designated Router (i.e., they are currently listing themselves as Designated
Router in their Hello Packets) the one having highest Router Priority Router in their Hello Packets) the one having highest Router Priority
is declared to be Designated Router. In case of a tie, the one is declared to be Designated Router. In case of a tie, the one
having the highest primary address is chosen. If no routers have having the highest primary address is chosen. If no routers have
declared themselves Designated Router, assign the Designated Router declared themselves Designated Router, assign the Designated Router
to be the same as the newly elected Backup Designated Router. to be the same as the newly elected Backup Designated Router.
skipping to change at page 10, line 14 skipping to change at page 10, line 18
be the new BDR. Then the "old" BDR will send the Prune message to be the new BDR. Then the "old" BDR will send the Prune message to
upstream routers. upstream routers.
As a result, the BDR is the one which has the highest priority except As a result, the BDR is the one which has the highest priority except
for DR. Once the DR is elected, the DR will not change until it for DR. Once the DR is elected, the DR will not change until it
fails or be manually adjusted. Once the DR and BDR are elected, the fails or be manually adjusted. Once the DR and BDR are elected, the
routers in the network MUST store the address of DR and BDR. routers in the network MUST store the address of DR and BDR.
4.6. Sender side 4.6. Sender side
DR/BDR function also can be used in source side that multiple routers DR/BDR function is also used in source side that multiple routers and
and source is in a same shared-media LAN. The algorithm is the same source is in a same shared-media LAN. The algorithm is the same as
as the receiver side. Only the BDR need not build multicast tree the receiver side. Only the BDR need not build multicast tree from a
from a downstream router. downstream router.
5. Compatibility 5. Compatibility
If the LAN is a hybrid network that there are some routers which If the LAN is a hybrid network that there are some routers which
support DR/BDR capability and the other routers which do not support support DR/BDR capability and the other routers which do not support
DR/BDR capability. All the routers MUST go backward to use the DR/BDR capability. All the routers MUST go backward to use the
election algorithm defined in [RFC7761]. And the values of DR and election algorithm defined in [RFC7761]. And the values of DR and
BDR carried in hello message SHOULD be set to zero. That is once a BDR carried in hello message MUST be set to zero. That is once a
router sends hello messages with no DR/BDR options, the DR election router sends hello messages with no DR/BDR options, the DR election
MUST go backward to the definition in [RFC7761]. MUST go backward to the definition in [RFC7761].
If the routers find that all the routers in the LAN support DR/BDR If the routers find that all the routers in the LAN support DR/BDR
capability by the hello messages with DR/BDR options set, they MUST capability by the hello messages with DR/BDR options set, they MUST
elect DR and BDR according the algorithm defined in this document. elect DR and BDR according the algorithm defined in this document.
And the routers MUST send hello messages with correct DR/BDR options And the routers MUST send hello messages with correct DR/BDR options
set. set.
In case there is only one router which does not support DR/BDR In case there is only one router which does not support DR/BDR
capability in a shared-media LAN, the other routers in the LAN send capability in a shared-media LAN, the other routers in the LAN send
hello messages with the values of DR and BDR are set to zero, the hello messages with the values of DR and BDR are set to zero, the
router which does not support DR/BDR capability ignores the options. router which does not support DR/BDR capability ignores the options.
All the routers elect DR according to the algorithm defined in All the routers elect DR according to the algorithm defined in
[RFC7761]. When the router which does not support DR/BDR capability [RFC7761]. When the router which does not support DR/BDR capability
goes away, the routers in the LAN MUST elect DR/BDR according to the goes away, the routers in the LAN MUST elect DR/BDR according to the
algorithm defined in this document, and send hello messages with algorithm defined in this document, and send hello messages with
correct DR/BDR options set. correct DR/BDR options set.
6. Deployment suggestion This draft allows DR election to be sticky by not unnecessarily
changing the DR when routers go down or come up. This is done by
If there are two or more routers which are responsible for multicast introducing new PIM Hello options. Both this draft, and the draft
flow forwarding on a shared-media LAN, and the multicast services are [I-D.mankamana-pim-bdr], introduce a backup DR. The latter draft
sensitive to the lost of multicast packets, the functions of DR and does this without introducing new options, but does not consider the
BDR, defined in this document, SHOULD be deployed. sticky behavior.
7. Security Considerations 6. Security Considerations
If an attacker which has the highest priority participates in the DR If an attacker which has the highest priority participates in the DR
election when a shared-media LAN starts to work, it will be elected election when a shared-media LAN starts to work, it will be elected
as DR, but it may not forward flows to receivers. And the attacker as DR, but it may not forward flows to receivers. And the attacker
remains DR position even if a legal router which has a higher remains DR position even if a legal router which has a higher
priority joins the LAN. priority joins the LAN.
If an attacker is a newcomer which has a higher priority than the If an attacker is a newcomer which has a higher priority than the
existed BDR, it will be elected as the new BDR, but it may not existed BDR, it will be elected as the new BDR, but it may not
monitor DR, import multicast flows and forward flows to receiver when monitor DR, import multicast flows and forward flows to receiver when
skipping to change at page 11, line 27 skipping to change at page 11, line 29
In order to avoid these situations, source authentication should be In order to avoid these situations, source authentication should be
used to identify the validity of the DR/BDR candidates. used to identify the validity of the DR/BDR candidates.
Authentication methods mentioned in section 6 RFC7761 can be used. Authentication methods mentioned in section 6 RFC7761 can be used.
And the network administrator should consider the potential BFD And the network administrator should consider the potential BFD
session attack if BFD is used between BDR and DR for DR failure session attack if BFD is used between BDR and DR for DR failure
detection. The security function mentioned in section 9 RFC5880 can detection. The security function mentioned in section 9 RFC5880 can
be used. be used.
8. IANA Considerations 7. IANA Considerations
IANA is requested to allocate two OptionTypes in TLVs of hello IANA is requested to allocate two OptionTypes in TLVs of hello
message. One type is used for DR and the other one is used for BDR. message: DR Address Option and BDR Address Option. The strings TBD1
and TBD2 will be replaced by the assigned values.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Greg Mirsky, Jake Holland, Stig The authors would like to thank Greg Mirsky, Jake Holland, Stig
Venaas for their valuable comments and suggestions. Venaas for their valuable comments and suggestions.
10. References 9. References
10.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>.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, DOI 10.17487/RFC2362, Protocol Specification", RFC 2362, DOI 10.17487/RFC2362,
skipping to change at page 12, line 15 skipping to change at page 12, line 21
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-pim-bfd-p2mp-use-case]
Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding
Detection (BFD) for Multi-point Networks and Protocol
Independent Multicast - Sparse Mode (PIM-SM) Use Case",
draft-ietf-pim-bfd-p2mp-use-case-02 (work in progress),
July 2019.
[I-D.mankamana-pim-bdr]
mishra, m., "PIM Backup Designated Router Procedure",
draft-mankamana-pim-bdr-02 (work in progress), April 2019.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
Authors' Addresses Authors' Addresses
skipping to change at page 12, line 34 skipping to change at page 13, line 4
Authors' Addresses Authors' Addresses
Zheng(Sandy) Zhang Zheng(Sandy) Zhang
ZTE Corporation ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct No. 50 Software Ave, Yuhuatai Distinct
Nanjing Nanjing
China China
Email: zhang.zheng@zte.com.cn Email: zhang.zheng@zte.com.cn
Fangwei Hu Fangwei Hu
ZTE Corporation Individual
No.889 Bibo Rd
Shanghai Shanghai
China China
Email: hu.fangwei@zte.com.cn Email: hufwei@gmail.com
Benchong Xu Benchong Xu
ZTE Corporation ZTE Corporation
No. 68 Zijinghua Road, Yuhuatai Distinct No. 68 Zijinghua Road, Yuhuatai Distinct
Nanjing Nanjing
China China
Email: xu.benchong@zte.com.cn Email: xu.benchong@zte.com.cn
Mankamana Mishra Mankamana Mishra
Cisco Systems Cisco Systems
821 Alder Drive, 821 Alder Drive,
MILPITAS, CALIFORNIA 95035 MILPITAS, CALIFORNIA 95035
UNITED STATES UNITED STATES
Email: mankamis@cisco.com Email: mankamis@cisco.com
 End of changes. 28 change blocks. 
63 lines changed or deleted 78 lines changed or added

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