<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dong-idr-node-target-ext-comm-04"
     ipr="trust200902">
  <front>
    <title abbrev="BGP Node Target Extended Community">BGP Extended Community
    for Identifying the Target Nodes</title>

    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

          <country>China</country>
        </postal>

        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>

    <author fullname="Gunter Van de Velde" initials="G."
            surname="Van de Velde">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street/>

          <city>Antwerp</city>

          <region/>

          <code/>

          <country>BE</country>
        </postal>

        <email>gunter.van_de_velde@nokia.com</email>
      </address>
    </author>

    <date day="12" month="July" year="2021"/>

    <abstract>
      <t>BGP has been used to distribute different types of routing and policy
      information. In some cases, the information distributed may be only
      intended for one or a particular group of BGP nodes in the network.
      Currently BGP does not have a generic mechanism of designating the
      target nodes of the routing information. This document defines a new
      type of BGP Extended Community called "Node Target". The mechanism of
      using the Node Target Extended Community to steer BGP route distribution
      to particular BGP nodes is specified.</t>
    </abstract>

    <note title="Requirements Language">
      <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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>BGP <xref target="RFC4271"/> has been used to distribute different
      types of routing and policy information. In some cases, the information
      distributed may be only intended for one or a particular group receiving
      BGP nodes in the network. One typical use case is the distribution of
      BGP Flow Spec <xref target="RFC8955"/> <xref target="RFC8956"/> rules
      only to a particular group of BGP nodes. Such a targeting mechanism is
      considered useful that it can save the resources on nodes which do not
      need that information.</t>

      <t>Currently BGP does not have a generic mechanism of designating the
      set of nodes to which the information is to be distributed. Route Target
      (RT) as defined in <xref target="RFC4364"/> was designed for the
      matching of VPN routes into the target VPN Routing and Forwarding tables
      (VRFs) on PE nodes. Although <xref
      target="I-D.ietf-idr-segment-routing-te-policy"/> introduces the
      mechanism of steering the SR policy information to the target head end
      node based on RT, it is only defined for the SR Policy Address Family.
      Although it is possible to reuse RTs to control the distribution of
      non-VPN information to one or a group of receiving nodes, such mechanism
      is not applicable when the information to be distributed is VPN-specific
      and is advertised with a set of RTs for the VRF matching. In that case,
      the matching of any of the VPN RTs in the Update will result in the
      information eligible for installation, regardless of whether the RTs
      representing the target nodes are matched or not. Thus a mechanism which
      is independent from the control of VPN route to VRF distribution is
      needed.</t>

      <t>Another possible approach is to configure, on each router, a
      community and the corresponding policies to match the community to
      determine whether to accept the received routes. Such mechanism relies
      on manual configuration thus is considered error-prone. It is preferable
      by some operators that an automatic approach can be provided, which
      would make the operation much easier.</t>

      <t>This document defines a new type of BGP Extended Community called
      "Node Target". The mechanism of using the Node Target extended community
      to steer BGP route distribution to particular BGP nodes is also
      specified.</t>
    </section>

    <section title="Node Target Extended Communities">
      <t>This section defines a new BGP Extended Community <xref
      target="RFC4360"/> called "Node Target Extended Community". It can be a
      transitive extended community with the high-order octect of the type set
      to 0x01, or a non-transitive extended community with the high-order
      octect type set to 0x41. The sub-type of the Node Target Extended
      Community is TBA.</t>

      <t>The format of Node Target Extended Community is shown in Figure
      1.</t>

      <t><figure>
          <artwork align="center"
                   name="Figure 1. IPv4 Node Target extended community"><![CDATA[    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  0x01 or 0x41 | Sub-Type(TBA) |    Target BGP Identifier      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Target BGP Identifier (cont.) |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1. Node Target extended community
]]></artwork>
        </figure>Where:</t>

      <t>Target BGP Identifier (4 octets): The BGP Identifier of a target
      node. It is a 4-octet, unsigned, non-zero integer as defined in <xref
      target="RFC6286"/>.</t>

      <t>Reserved field (2 octets): Reserved for future use, MUST be set to
      zero on transmission and ignored on receipt.</t>

      <t>One or more Node Target extended communities MAY be carried in an
      Update message to designate a group of target BGP nodes.</t>
    </section>

    <section title="Procedures">
      <t>In this section, the mechanism for intra-domain scenario is
      described, the mechanism for inter-domain scenario is for further study.
      The domain here refers to an administrative domain, which may consists
      of one or multiple ASes managed by a single operator.</t>

      <t>When a network controller or BGP speaker plans to advertise some BGP
      routing or policy information only to one or a group of BGP nodes in the
      network, it MUST put the BGP Identifier of each target node into the
      Node Target extended communities, and attach the Node Target extended
      communities to the routes or policies to be advertised.</t>

      <t>When a BGP speaker receives a BGP Update which contains one or more
      Node Target extended communities, it MUST check the target BGP
      Identifiers carried in the Node Target extended communities of the
      Update.</t>

      <t><list style="symbols">
          <t>If the target BGP Identifier in any of the Node Target extended
          community matches with the local BGP Identifier, this node is one of
          the target nodes of the Update, the information in the Update is
          eligible to be kept and installed on this node.<list style="symbols">
              <t>If this node is a Route Reflector, and in the Update there is
              one or more Node Target extended communities which contains
              non-local BGP Identifiers, information in the Update are
              eligible be reflected to its peers according to the rules
              defined in <xref target="RFC4456"/>. Depends on a configurable
              policy, the RR MAY check the BGP Identifiers of its peers to
              determine the set of peers which are the target nodes of the
              Update, and only reflect the information in the Update to the
              matched BGP peers.</t>

              <t>If this node is an Autonomous System Border Router (ASBR),
              and the BGP Identifiers of one or more of its EBGP peers match
              with the Node Target extended communities in the Update,
              information in the Update is eligible to be advertised to the
              matched EBGP peers.</t>
            </list></t>

          <t>If the target BGP Identifier in any of the Node target extended
          community does not match with the local BGP Identifier, this node is
          not the target node of Update, the information in the Update is not
          eligible to be installed on this node.<list style="symbols">
              <t>If this node is a Route Reflector, information in the Update
              is eligible to be reflected to its peers according to the rules
              defined in <xref target="RFC4456"/>. Depends on a configurable
              policy, the RR MAY check the BGP Identifiers of its peers to
              determine the set of peers which are the target nodes of the
              Update, and only reflect the information in the Update to the
              matched BGP peers.</t>
            </list></t>
        </list></t>
    </section>

    <section title="Compatibility Considerations">
      <t>The Node Target extended community introduced in this document can be
      deployed incrementally in the network. For BGP speakers which understand
      the Node Target extended community, it is used to determine whether the
      nodes are the target nodes of the Update. For BGP speakers which do not
      understand the Node Target extended community, it will be ignored and
      the information in the Update will be processed and advertised based on
      normal BGP procedure. Although this could ensure that the target nodes
      can always obtain the information needed, this may result in unnecessary
      state maintained on legacy BGP speakers. And if the information
      advertised is the Flow Spec rules, the legacy BGP speakers may install
      unnecessary flowspec rules, this may have impact on traffic which
      matches such rules, thus may result in unexpected traffic steering or
      filtering behaviors on such nodes. This may be mitigated by setting
      appropriate routing policies on the legacy BGP nodes.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests that IANA assigns one new sub-type for "Node
      Target Extended Community" from the "Transitive IPv4-Address-Specific
      Extended Community" registry of the "BGP Eextended Communities"
      registry.</t>

      <t>This document requests that IANA assigns the same sub-type for "Node
      Target Extended Community" from the "Non-Transitive
      IPv4-Address-Specific Extended Community" registry of the "BGP Eextended
      Communities" registry.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[Haibo Wang
Email: rainsword.wang@huawei.com]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Zhenbin Li, Ercin Torun, Jeff Haas,
      Robert Raszuk and John Scudder for the review and discussion of this
      document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.4360'?>

      <?rfc include='reference.RFC.4456'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4364'?>

      <?rfc include='reference.RFC.5575'?>

      <?rfc include='reference.RFC.6286'?>

      <?rfc include='reference.RFC.8955'?>

      <?rfc include='reference.RFC.8956'?>

      <?rfc include='reference.I-D.ietf-idr-segment-routing-te-policy'?>
    </references>
  </back>
</rfc>
