PIM WG                                                          Z. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                                   F. Hu
Expires: April 3, 2021                                        Individual
                                                                   B. Xu
                                                         ZTE Corporation
                                                               M. Mishra
                                                           Cisco Systems
                                                      September 30, 2020


Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router
                            (DR) Improvement
                    draft-ietf-pim-dr-improvement-10

Abstract

   Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely
   deployed multicast protocol.  As deployment for the PIM protocol is
   growing day by day, a user expects lower packet loss and faster
   convergence regardless of the cause of the network failure.  This
   document defines an extension to the existing protocol, which
   improves the PIM protocol's stability with respect to packet loss and
   convergence time when the PIM Designated Router (DR) role changes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 3, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Zhang, et al.             Expires April 3, 2021                 [Page 1]


Internet-Draft             PIM DR Improvement             September 2020


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Election Algorithm  . . . . . . . . . . . . . . . . . . .   5
     3.2.  Sending Hello Messages  . . . . . . . . . . . . . . . . .   5
     3.3.  Receiving Hello Messages  . . . . . . . . . . . . . . . .   6
     3.4.  Working with the DRLB function  . . . . . . . . . . . . .   6
   4.  PIM Hello message format  . . . . . . . . . . . . . . . . . .   7
     4.1.  DR Address Option format  . . . . . . . . . . . . . . . .   7
     4.2.  BDR Address Option format . . . . . . . . . . . . . . . .   7
     4.3.  Error handling  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Multicast technology, with PIM-SM ([RFC7761]), is used widely in
   modern services like IPTV and Net-Meeting.  Some events, such as
   changes in unicast routes, or a change in the PIM-SM DR, may cause
   the loss of multicast packets.

   The PIM DR has two responsibilities in the PIM-SM protocol.  For any
   active sources on a LAN, the PIM DR is responsible for registering
   with the Rendezvous Point (RP) if the group is operating in PIM-SM.
   Also, the PIM DR is responsible for tracking local multicast
   listeners and forwarding data to these listeners if the group is
   operating in PIM-SM.





Zhang, et al.             Expires April 3, 2021                 [Page 2]


Internet-Draft             PIM DR Improvement             September 2020


                           +                  +
                           |                  |
                     +-----+----+       +-----+----+
                     | RouterA  |       | RouterB  |
                     +-----+----+       +-----+----+
                           |                  |
                 +----+----+--------+---------+---+----+
                      |             |             |
                      +             +             +
                  Receiver1     Receiver2     Receiver3
                 Figure 1: An example of multicast network

   The simple network in Figure 1 presents two routers (A and B)
   connected to a shared-media LAN segment.  Two different scenarios are
   described to illustrate potential issues.

   (a) Both routers are on the network, and RouterB is elected as the
   DR.  If RouterB then fails, multicast packets are discarded until
   RouterA is elected as DR and it assumes the multicast flows on the
   LAN.  As detailed in [RFC7761], a DR's election is triggered after
   the current DR's Hello_Holdtime expires.  When the DR (RouterB) is
   deemed unavailable, as the result of DR failure detection, RouterA is
   elected as the DR.  Then RouterA joins the multicast trees, starts
   receiving the flows and proceeds with the multicast forwarding.  All
   the procedures usually take several seconds.  That is too long for
   modern multicast services.

   (b) Only RouterA is initially on the network, making it the DR.  If
   RouterB joins the network with a higher DR Priority.  Then it will
   then be elected as DR.  RouterA will stop forwarding multicast
   packets, and the multicast flows will not recover until RouterB
   assumes the multicast flows on the LAN.

   In either of the situations listed, many multicast packets are lost,
   and the quality of multicast services noticeably affected.  To
   increase the stability of the network, this document introduces the
   Designated DR (DR) and Backup Designated Router (BDR) options and
   specifies how its identity is explicitly advertised.

1.1.  Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.





Zhang, et al.             Expires April 3, 2021                 [Page 3]


Internet-Draft             PIM DR Improvement             September 2020


2.  Terminology

   Backup Designated Router (BDR): Immediately takes over all DR
   functions ([RFC7761]) on an interface once the DR is no longer
   present.  A single BDR SHOULD be elected per interface.

   Designated Router Other (DROther): A router which is neither a DR nor
   a BDR.

   0x0: 0.0.0.0 if IPv4 addresses are in use or 0:0:0:0:0:0:0:0/128 if
   IPv6 addresses are in use.  To simplify, 0x0 is used in abbreviation
   in this draft.

3.  Protocol Specification

   The router follows the following procedures:

   (a).  A router first starts sending Hello messages with the values of
   DR and BDR Address options are all set to 0x0, after its interface is
   enabled in PIM on a shared-media LAN.  The router treats itself as
   DROther role, and starts a timer which value is set to
   Hello_Holdtime.

   (b).  When the router receives Hello messages from other routers on
   the same shared-media LAN, the router checks the value of DR/BDR
   Address option.  If the value is filled with a non-zero IP address,
   the router stores the IP addresses.

   (c).  When a Hello message with a non-zero DR Address option is
   received or after the timer expires, the router first executes the
   algorithm defined in section 3.1.  After that, the router first one
   of the roles in the LAN: DR, BDR, or DROther.

   If the role of the router first starts changes to BDR, the following
   steps are:

   o  The BDR takes on all the functions of a DR as specified in
      [RFC7761], except that it SHOULD NOT actively forward multicast
      flows or send a register message to avoid duplication.

   o  If the DR becomes unreachable on the LAN, the BDR MUST take over
      all the DR functions, including multicast flow forwarding or send
      the register message.  Mechanisms outside the scope of this
      specification, such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD
      Asynchronous mode [RFC5880] can be used for faster failure
      detection.





Zhang, et al.             Expires April 3, 2021                 [Page 4]


Internet-Draft             PIM DR Improvement             September 2020


   For example, there are three routers: A, B, and C.  If all three were
   in the LAN, then their DR preference would be A, B, and C, in that
   order.  Initially, only C is on the LAN, so C is DR.  Later, A joins;
   C is still the DR, and A is the BDR.  Later B joins, and if B is
   better than A, then B becomes the BDR, and A is simply DROther.

3.1.  Election Algorithm

   The DR and BDR election is according to the DR election algorithm
   defined in section 9.4 in [RFC2328], except:

   o  The DR is elected among the DR candidates directly.  If there is
      no DR candidates, i.e., no router advertise the DR Address options
      with a non-zero IP address, the elected BDR will be the DR.  And
      then the BDR is elected again from the other routers in the LAN.

   o  The BDR election is not sticky.  Whatever there is a router that
      advertise the BDR Address option, the router which has the highest
      priority, expect the elected DR, is elected as the BDR.  That is
      the BDR may be the router which has the highest priority in the
      LAN.

   o  The advertisement is through PIM Hello message.

   o  Step 6 and 7 in section 9.4 in [RFC2328] are not applicable here.

   Compare to the DR election function defined in section 4.3.2 in
   [RFC7761] the differences include:

   o  The router, that can be elected as DR, has the highest priority
      among the DR candidates.  The elected DR may not be the one that
      has the highest priority in the LAN.

   o  The router that supports the election algorithm defined in section
      3.1 MUST advertise the DR Address option defined in section 4.1 in
      PIM Hello message, and SHOULD advertise the BDR Address option
      defined in section 4.2 in PIM Hello message.  In case a DR is
      elected and no BDR is elected, only the DR Address option is
      advertised in the LAN.

3.2.  Sending Hello Messages

   When PIM is enabled on an interface or a router first starts, Hello
   messages MUST be sent with the values of the DR Address option filled
   with 0x0.  The BDR Address option SHOULD be sent, if the option is
   carried, the value MUST be filled with 0x0.  Then the interface
   starts a timer which value is set to Hello_Holdtime.  When the timer




Zhang, et al.             Expires April 3, 2021                 [Page 5]


Internet-Draft             PIM DR Improvement             September 2020


   expires, the DR and BDR will be elected on the interface according to
   the DR election algorithm (Section 3.1).

                  DR                                newcomer
                   \                                  /
                    -----       -----           -----
                    | A |       | B |           | C |
                    -----       -----           -----
                      |           |               |
                      |           |               |
              ------------------------------------------- LAN
                               Figure 2

   For example, there is a stable LAN that includes RouterA and RouterB.
   RouterA is the DR that has the highest priority.  RouterC is a
   newcomer.  RouterC sends a Hello message with the DR and BDR Address
   options are all set to zero.

   When a router first starts (RouterC) elects itself as the BDR after
   it running the election algorithm, the router sends Hello messages
   with the value of DR is set to the IP address of current DR (RouterA)
   and the value of BDR is set to the IP address of the router first
   starts itself (RouterC).

   A current BDR (RouterB) may find that it can not be the BDR after it
   running the election algorithm, it MUST set itself DROther and stop
   sending the BDR Address options with its IP address.  It MUST send
   Hello messages with the value of DR is set to current DR and the
   value of BDR is set to the newly elected BDR.

3.3.  Receiving Hello Messages

   When a Hello message is received, if the DR/BDR Address option
   carried in the message is different from the previous message.  The
   election algorithm MUST be rerun.  As a result, the associate actions
   should be taken according to the role changing.

3.4.  Working with the DRLB function

   The DRLB function defined in [RFC8775] can work with the mechanism
   defined in this document.  The routers advertise the DR/BDR Address
   options and the DRLB-Cap Hello Option defined in [RFC8775].  After
   running the election algorithm defined in section 3.1, the elected DR
   advertises the DRLB-List Hello Option to carry the GDR candidates.

   When the current DR is unavailable, the BDR MUST send the DRLB-List
   Hello Option to carry the GDR candidates.  The BDR starts forwarding




Zhang, et al.             Expires April 3, 2021                 [Page 6]


Internet-Draft             PIM DR Improvement             September 2020


   the multicast flows, but there may be duplicated flows because the DR
   may not be the same as the GDR.

4.  PIM Hello message format

   Two new PIM Hello Options are defined, which conform to the format
   defined in [RFC7761].

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          OptionType           |         OptionLength          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          OptionValue                          |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 3: Hello Option Format

4.1.  DR Address Option format

   o  OptionType : The value is 37.

   o  OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6.

   o  OptionValue: IP address of the DR.  If the IP version of the PIM
      message is IPv4, the value MUST be the IPv4 address of the DR.  If
      the IP version of the PIM message is IPv6, the value MUST be the
      link-local address of the DR.

4.2.  BDR Address Option format

   o  OptionType : The value is 38.

   o  OptionLength: 4 bytes if using IPv4 and 16 bytes if using IPv6.

   o  OptionValue: IP address of the BDR.  If the IP version of the PIM
      message is IPv4, the value MUST be the IPv4 address of the BDR.
      If the IP version of the PIM message is IPv6, the value MUST be
      the link-local address of the BDR.

4.3.  Error handling

   The DR and BDR addresses MUST be the same with the addresses which
   are used to send PIM Hello message.

   Unknown options MUST be ignored, which conforms to the format defined
   in section 4.9.2 in [RFC7761], and the options MUST be ignored that
   include unexpected values.  For example, when a DR Address option



Zhang, et al.             Expires April 3, 2021                 [Page 7]


Internet-Draft             PIM DR Improvement             September 2020


   with IPv4 address is received while the interface supports IPv6 only,
   the option MUST be ignored.

5.  Compatibility

   If at least one router on a LAN doesn't send a Hello message,
   including the DR Address Options, then the specification in this
   document MUST NOT be used.  Any router using the DR and BDR Address
   Options MUST set the corresponding OptionValues to 0x0.  This action
   results in all routers using the DR election function defined in
   [RFC7761] or [I-D.mankamana-pim-bdr].

   This draft allows the DR election to be sticky by not unnecessarily
   changing the DR when routers go down or come up.  That is done by
   introducing new PIM Hello options.  Both this draft and the draft
   [I-D.mankamana-pim-bdr], introduce a backup DR.  The latter draft
   does this without introducing new options but does not consider the
   sticky behavior.

   A router that does not support this specification ignores unknown
   options According to section 4.9.2 defined in [RFC7761].  So the new
   extension defined in this draft will not influence the stability of
   neighbors.

   The DR election mechanism selection would depend on deployment
   scenario.

6.  Security Considerations

   [RFC7761] describes the security concerns related to PIM-SM, the
   potential BFD session attack can be used as the security function in
   section 9 [RFC5880] mentioned.

   If an attacker wants to hijack the DR role, it may send PIM Hello
   message with the altered DR/BDR Address options.  The attacker sends
   the Hello message with the DR Address option set to itself as DR
   except for the highest priority or IP address.  Or the attacker sends
   the Hello message without the DR/BDR Address option except for the
   highest priority or IP address.

   If an attacker wants to take the BDR role, it simply sends PIM Hello
   message with BDR Address options except for the higher priority or IP
   address than the current BDR.

   Some security measures, such as IP address filtering for the
   election, may be taken to avoid these situations.  For example, the
   Hello message received from an unknown neighbor is ignored by the
   election process.



Zhang, et al.             Expires April 3, 2021                 [Page 8]


Internet-Draft             PIM DR Improvement             September 2020


7.  IANA Considerations

   IANA is requested to allocate two new code points from the "PIM-Hello
   Options" registry.

               +------+--------------------+---------------+
               | Type | Description        | Reference     |
               +------+--------------------+---------------+
               | 37   | DR Address Option  | This Document |
               | 38   | BDR Address Option | This Document |
               +------+--------------------+---------------+

                                  Table 1

8.  Acknowledgements

   The authors would like to thank Alvaro Retana, Greg Mirsky, Jake
   Holland, Stig Venaas for their valuable comments and suggestions.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.






Zhang, et al.             Expires April 3, 2021                 [Page 9]


Internet-Draft             PIM DR Improvement             September 2020


   [RFC8775]  Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S.,
              and A. Green, "PIM Designated Router Load Balancing",
              RFC 8775, DOI 10.17487/RFC8775, April 2020,
              <https://www.rfc-editor.org/info/rfc8775>.

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-04 (work in progress),
              July 2020.

   [I-D.mankamana-pim-bdr]
              mishra, m., Goh, J., and G. Mishra, "PIM Backup Designated
              Router Procedure", draft-mankamana-pim-bdr-04 (work in
              progress), April 2020.

Authors' Addresses

   Zheng(Sandy) Zhang
   ZTE Corporation
   No. 50 Software Ave, Yuhuatai Distinct
   Nanjing
   China

   Email: zhang.zheng@zte.com.cn


   Fangwei Hu
   Individual
   Shanghai
   China

   Email: hufwei@gmail.com


   Benchong Xu
   ZTE Corporation
   No. 68 Zijinghua Road, Yuhuatai Distinct
   Nanjing
   China

   Email: xu.benchong@zte.com.cn






Zhang, et al.             Expires April 3, 2021                [Page 10]


Internet-Draft             PIM DR Improvement             September 2020


   Mankamana Mishra
   Cisco Systems
   821 Alder Drive,
   MILPITAS, CALIFORNIA 95035
   UNITED STATES

   Email: mankamis@cisco.com












































Zhang, et al.             Expires April 3, 2021                [Page 11]