Network Working Group                                          S. Venaas
Internet-Draft                                              IJ. Wijnands
Intended status: Experimental                                  M. Mishra
Expires: April 25, 2019                              Cisco Systems, Inc.
                                                            M. Sivakumar
                                                        Juniper Networks
                                                        October 22, 2018


          PIM Flooding Mechanism and Source Discovery for BIER
                      draft-venaas-bier-pfm-sd-00

Abstract

   PIM Flooding Mechanism and Source Discovery (PFM-SD) is a mechanism
   for source discovery within a PIM domain.  PIM signaling over BIER
   has been defined, allowing for BIER to interoperate with PIM.  This
   document defines PFM-SD over BIER, such that PFM-SD can be used by
   PIM in a PIM domain to discover sources that are reachable via BIER.
   Also, this document provides PFM-SD extensions to discover the BIER
   ingress router closest to the source.  This can be used by BIER
   overlays, such as PIM signaling over BIER, to determine which router
   to signal.

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 25, 2019.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Venaas, et al.           Expires April 25, 2019                 [Page 1]


Internet-Draft        PIM Source Discovery for BIER         October 2018


   (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.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  PFM over BIER . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  PFM Ingress BIER Router TLV . . . . . . . . . . . . . . . . .   3
   4.  Group Source Holdtime Metric TLV  . . . . . . . . . . . . . .   4
   5.  BIER signaling enhancements . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   PIM Flooding Mechanism (PFM) and Source Discovery (SD) [RFC8364]
   provides a generic flooding mechanism for distributing information
   throughout a PIM domain.  In particular it allows for source
   discovery.  There are various deployment scenarios where PIM and BIER
   need to co-exist.  For instance, consider migration scenarios where a
   few routers in a PIM domain are upgraded to support BIER.  In that
   case, one may use PIM Signaling Through BIER Core
   [I-D.ietf-bier-pim-signaling], allowing PIM to build trees passing
   through the BIER routers.  This document defines PFM over BIER.  This
   allows PFM to pass through the BIER routers, allowing PFM to be used
   in the PIM domain.

   One challenge with PIM signaling over BIER
   [I-D.ietf-bier-pim-signaling] is to determine which BIER router is
   closest to the source.  A number of options are discussed in that
   document.  This document provides an alternative solution for
   discovering which BIER router to signal.  It may also be used with
   other signaling mechanisms such as IGMP/MLD [I-D.ietf-bier-mld].
   This is achieved by introducing two new PFM TLVs.  When a BIER router
   forwards a PFM message into BIER, it adds a new TLV specifying the
   BIER sub-domain, its BFR-ID and its BIER prefix.  Also, any Group
   Source Holdtime TLVs, defined in [RFC8364], are replaced with new
   TLVs that include the router's cost of reaching the sources.



Venaas, et al.           Expires April 25, 2019                 [Page 2]


Internet-Draft        PIM Source Discovery for BIER         October 2018


1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  PFM over BIER

   When a BIER enabled router accepts a PFM message from a PIM neighbor
   according to [RFC8364], it SHOULD in addition to the forwarding
   defined in [RFC8364], also send a copy to all BIER routers (an
   implementation SHOULD allow the set of BIER routers to send PFM
   messages to, to be configured).

   When a router receives a BIER encapsulated PFM message, it MUST
   process the message according to [RFC8364], except there is no
   requirement for the message to come from a PIM neighbor, and there is
   no RPF check.  The message MUST be forwarded out on the PIM
   interfaces according to [RFC8364].  It MAY also be BIER forwarded, if
   the router acts as a border router between BIER domains.

3.  PFM Ingress BIER Router TLV

   When a router is forwarding a PFM message into a BIER domain, it MUST
   add this TLV.  If the TLV is already present, all occurrences should
   be removed.  This TLV encodes the BIER prefix, sub-domain ID and BFR-
   ID of the router.  This TLV SHOULD only be present within the BIER
   domain.  When a router receives a PFM message with this TLV, all
   occurrences of the TLV SHOULD be removed.  If the router is
   forwarding the message into a new BIER domain, it should add a new
   TLV with its own prefix, sub-domain ID and BFR-ID.  A PFM message is
   expected to have at most one such TLV.  A router MUST NOT add more
   than one such TLV.  When forwarding a PFM message, the TLV in the
   received message MUST be removed from the forwarded message.

       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|         Type = TBD          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-domain-id |   Reserved    |           BFR-id              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   BFR-prefix (4 or 16 octets)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   0:   The Transitive bit is set to 0.

   Type:   Type is TBD.



Venaas, et al.           Expires April 25, 2019                 [Page 3]


Internet-Draft        PIM Source Discovery for BIER         October 2018


   Length:   The length of the value in octets.

   Sub-domain-id:   The ID of the sub-domain that this PFM is forwarded
      into.  The length is 1 octet.

   Reserved:   MUST be set to 0, and ignored when received.  The length
      is 1 octet.

   BFR-id:   The BFR-id of the router that added this TLV in the sub-
      domain specified.  The length is 2 octets.

   BFR-prefix:   The BFR-prefix of the router that added this TLV in the
      sub-domain specified.  This length is 4 octets for IPv4 and 16
      octets for IPv6.

4.  Group Source Holdtime Metric TLV

   When a router forwards a PFM message into a BIER domain, it should
   replace all Group Source Holdtime TLVs defined in [RFC8364] with the
   Group Source Holdtime Metric TLVs defined here.  They are the same,
   except here we also add metric preference and metric.  The metric
   preference and metric MUST be set to this router's metric and
   preference to reach the specified source.  If the source is not
   reachable, the TLV MUST be omitted.  This TLV is used together with
   the PFM Ingress BIER Router TLV is used to indicate the ingress
   router's cost of reaching the source.

   When a router receives a message containing this TLV, it SHOULD store
   this information, but it MUST NOT forward these TLVs.  If forwarding
   into another BIER domain, the metric preference and metric MUST be
   updated with this router's cost of reaching the source.  If
   forwarding into a PIM domain, all the TLVs SHOULD be replaced with
   Group Source Holdtime TLVs as defined in [RFC8364].  The same
   information is used, except that the metric preference and metric are
   left out.  One could potentially make use of the metric in a PIM
   domain as well, but it is not clear whether this is useful, and the
   PIM routers may not support this TLV.














Venaas, et al.           Expires April 25, 2019                 [Page 4]


Internet-Draft        PIM Source Discovery for BIER         October 2018


       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|         Type = TBD          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Group Address (Encoded-Group format)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Src Count          |        Src Holdtime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Src Address 1 (Encoded-Unicast format)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Metric Preference 1                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Metric 1                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Src Address 2 (Encoded-Unicast format)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Metric Preference 2                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Metric 2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Src Address m (Encoded-Unicast format)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Metric Preference m                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Metric m                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   0:   The Transitive bit is set to 0.

   Type:   Type is TBD.

   Length:   The length of the value in octets.

   Group Address:   The group that sources are to be announced for.  The
      format for this address is given in the Encoded-Group format in
      [RFC7761].

   Src Count:   The number of source addresses that are included.

   Src Holdtime:   The Holdtime (in seconds) for the included source(s).

   Src Address:   The source address for the corresponding group.  The
      format for these addresses is given in the Encoded-Unicast address
      in [RFC7761].



Venaas, et al.           Expires April 25, 2019                 [Page 5]


Internet-Draft        PIM Source Discovery for BIER         October 2018


   Metric Preference:   Preference value assigned to the unicast routing
      protocol that provided the route to the source.

   Metric:   The unicast routing table metric associated with the route
      used to reach the source.  The metric is in units applicable to
      the unicast routing protocol used.

5.  BIER signaling enhancements

   A BIER border router SHOULD cache all the Group Source Holdtime
   Metric TLVs it receives, along with the respective PFM Ingress BIER
   Router TLV.  This allows the router to determine which sources are
   active, and which BIER border router is closest to the source.  The
   sub-domain ID, BFR-id and BFR-prefix in the TLV provide the necessary
   information for use by signaling mechanisms such as
   [I-D.ietf-bier-pim-signaling] to signal the preferred ingress router.
   It may also be used by [I-D.ietf-bier-mld].  IGMP/MLD reports would
   generally be sent to all BIER routers as it is not known which
   sources are active and which routers can reach them.  But by using
   the enhancements in this document, a source-specific report can be
   sent to the router closest to the source.  Also a group report might
   be set to the set of routers that are closest to the sources for that
   group.  This reduces the amount of receiver state on the BIER
   routers, and also the amount of messages each routers needs to
   process.

6.  Security Considerations

   TBD

7.  IANA Considerations

   This document defines two new PFM TLVs that needs to be assigned from
   the "PIM Flooding Mechanism Message Types" registry.

8.  References

8.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>.








Venaas, et al.           Expires April 25, 2019                 [Page 6]


Internet-Draft        PIM Source Discovery for BIER         October 2018


   [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>.

   [RFC8364]  Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
              Flooding Mechanism (PFM) and Source Discovery (SD)",
              RFC 8364, DOI 10.17487/RFC8364, March 2018,
              <https://www.rfc-editor.org/info/rfc8364>.

8.2.  Informative References

   [I-D.ietf-bier-mld]
              Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang,
              Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay
              using Multicast Listener Discovery Protocols", draft-ietf-
              bier-mld-01 (work in progress), June 2018.

   [I-D.ietf-bier-pim-signaling]
              Bidgoli, H., Dolganow, A., Kotalwar, J., Xu, F., mishra,
              m., and Z. Zhang, "PIM Signaling Through BIER Core",
              draft-ietf-bier-pim-signaling-04 (work in progress),
              October 2018.

Authors' Addresses

   Stig Venaas
   Cisco Systems, Inc.
   Tasman Drive
   San Jose  CA  95134
   USA

   Email: stig@cisco.com


   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com








Venaas, et al.           Expires April 25, 2019                 [Page 7]


Internet-Draft        PIM Source Discovery for BIER         October 2018


   Mankamana Mishra
   Cisco Systems, Inc.
   Tasman Drive
   San Jose  CA  95134
   USA

   Email: mankamis@cisco.com


   Mahesh Sivakumar
   Juniper Networks
   1133 Innovation Way
   Sunnyvale  CA 94089
   USA

   Email: sivakumar.mahesh@gmail.com



































Venaas, et al.           Expires April 25, 2019                 [Page 8]