<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE rfc SYSTEM "rfc2629.dtd" []><rfc category="exp" ipr="trust200902" docName="draft-venaas-bier-pfm-sd-00"><?rfc toc="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><?rfc symrefs="yes"?><front>    <title abbrev="PIM Source Discovery for BIER">PIM Flooding Mechanism and Source Discovery for BIER</title>    <author initials="S." surname="Venaas" fullname="Stig Venaas">      <organization>Cisco Systems, Inc.</organization>      <address>        <postal>          <street>Tasman Drive</street>          <city>San Jose</city>          <code>CA  95134</code>          <country>USA</country>        </postal>        <email>stig@cisco.com</email>      </address>          </author>    <author initials="IJ." surname="Wijnands" fullname="IJsbrand Wijnands">      <organization>Cisco Systems, Inc.</organization>      <address>        <postal>          <street>De kleetlaan 6a</street>          <city>Diegem</city>          <code>1831</code>          <country>Belgium</country>        </postal>        <email>ice@cisco.com</email>      </address>          </author>    <author initials="M." surname="Mishra" fullname="Mankamana Mishra">      <organization>Cisco Systems, Inc.</organization>      <address>        <postal>          <street>Tasman Drive</street>          <city>San Jose</city>          <code>CA  95134</code>          <country>USA</country>        </postal>        <email>mankamis@cisco.com</email>      </address>          </author>    <author fullname="Mahesh Sivakumar" initials="M." surname="Sivakumar">      <organization>Juniper Networks</organization>      <address>        <postal>          <street>1133 Innovation Way</street>          <city>Sunnyvale</city>          <code>CA 94089</code>          <country>USA</country>        </postal>        <email>sivakumar.mahesh@gmail.com</email>      </address>    </author>    <date/>    <area>Routing</area>    <keyword>Multicast</keyword>    <abstract>      <t>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.      </t>    </abstract></front><middle>  <section title="Introduction">    <t>PIM Flooding Mechanism (PFM) and Source Discovery (SD)<xref target='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<xref target='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.    </t>    <t>One challenge with PIM signaling over BIER<xref target='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 <xref target='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 <xref target='RFC8364'/>, are replaced with new TLVs thatinclude the router's cost of reaching the sources.    </t>    <section title="Conventions Used in This Document">      <t>        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 <xref target='RFC2119'/>.      </t>    </section>  </section>  <section title="PFM over BIER">    <t>When a BIER enabled router accepts a PFM message from a PIM neighboraccording to <xref target='RFC8364'/>, it SHOULD in addition to theforwarding defined in <xref target='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).    </t>    <t>When a router receives a BIER encapsulated PFM message, it MUSTprocess the message according to <xref target='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 <xref target='RFC8364'/>. It MAY also be BIER forwarded, ifthe router acts as a border router between BIER domains.    </t>  </section>  <section title="PFM Ingress BIER Router TLV">    <t>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.    </t>    <t>      <figure>        <artwork>    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)                 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        </artwork>      </figure>    </t>    <t>      <list style='hanging'>        <t hangText='0: '>          The Transitive bit is set to 0.        </t>        <t hangText='Type: '>          Type is TBD.        </t>        <t hangText='Length: '>          The length of the value in octets.        </t>        <t hangText='Sub-domain-id: '>          The ID of the sub-domain that this PFM is forwarded into.          The length is 1 octet.        </t>        <t hangText='Reserved: '>          MUST be set to 0, and ignored when received.          The length is 1 octet.        </t>        <t hangText='BFR-id: '>          The BFR-id of the router that added this TLV in the sub-domain          specified. The length is 2 octets.        </t>        <t hangText='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.        </t>      </list>    </t>  </section>  <section title="Group Source Holdtime Metric TLV">    <t>When a router forwards a PFM message into a BIER domain, it shouldreplace all Group Source Holdtime TLVs defined in<xref target='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.    </t>    <t>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 <xref target='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.    </t>    <t>      <figure>        <artwork>    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                           |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        </artwork>      </figure>    </t>    <t>      <list style='hanging'>        <t hangText='0: '>          The Transitive bit is set to 0.        </t>        <t hangText='Type: '>          Type is TBD.          </t>          <t hangText='Length: '>            The length of the value in octets.          </t>          <t hangText='Group Address: '>            The group that sources are to be announced for. The format            for this address is given in the Encoded-Group format in            <xref target='RFC7761'/>.          </t>          <t hangText='Src Count: '>            The number of source addresses that are included.          </t>          <t hangText='Src Holdtime: '>            The Holdtime (in seconds) for the included source(s).                 </t>          <t hangText='Src Address: '>            The source address for the corresponding group.            The format for these addresses is given in the Encoded-Unicast            address in <xref target='RFC7761'/>.          </t>          <t hangText='Metric Preference: '>            Preference value assigned to the unicast routing protocol that            provided the route to the source.          </t>          <t hangText='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.          </t>      </list>    </t>  </section>  <section title="BIER signaling enhancements">    <t>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 <xref target='I-D.ietf-bier-pim-signaling'/> to signal thepreferred ingress router.It may also be used by <xref target='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.    </t>  </section>  <section title="Security Considerations">    <t>TBD</t>  </section>    <section title="IANA Considerations">    <t>This document defines two new PFM TLVs that needs to be assigned fromthe "PIM Flooding Mechanism Message Types" registry.    </t>  </section></middle><back>  <references title='Normative References'>    <?rfc include='reference.RFC.2119' ?>    <?rfc include='reference.RFC.7761' ?>    <?rfc include='reference.RFC.8364' ?>  </references>    <references title='Informative References'>    <?rfc include="reference.I-D.ietf-bier-pim-signaling" ?>    <?rfc include="reference.I-D.ietf-bier-mld" ?>  </references>  </back></rfc>