draft-cppy-grow-bmp-path-info-tlv-00.xml

<?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-cppy-grow-bmp-path-info-tlv-00"
     ipr="trust200902">
  <front>
    <title abbrev="BMP path information tlv">BMP Extension for Path
    Information TLV</title>

    <author fullname="Camilo Cardona" initials="C." surname="Cardona">
      <organization>NTT</organization>

      <address>
        <postal>
          <street>164-168, Carrer de Numancia</street>

          <city>Barcelona</city>

          <code>08029</code>

          <country>Spain</country>
        </postal>

        <email>camilo@ntt.net</email>
      </address>
    </author>

    <author fullname="Paolo Lucente" initials="P." surname="Lucente">
      <organization>NTT</organization>

      <address>
        <postal>
          <street>Siriusdreef 70-72</street>

          <city>Hoofddorp</city>

          <region>WT</region>

          <code>2132</code>

          <country>Netherlands</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>paolo@ntt.net</email>

        <uri/>
      </address>
    </author>

    <author fullname="Pierre Francois" initials="P." surname="Francois">
      <organization>INSA-Lyon</organization>

      <address>
        <postal>
          <street/>

          <city>Lyon</city>

          <code/>

          <country>France</country>
        </postal>

        <email>Pierre.Francois@insa-lyon.fr</email>
      </address>
    </author>

    <author fullname="Yunan Gu" initials="Y. " surname="Gu">
      <organization>Huawei</organization>

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

          <city>Beijing</city>

          <code>100095</code>

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

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

    <author fullname="Thomas Graf" initials="T. " surname="Graf">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street>Binzring 17</street>

          <city>Zurich</city>

          <code>8045</code>

          <country>Switzerland</country>
        </postal>

        <email>thomas.graf@swisscom.com</email>
      </address>
    </author>

    <date day="06" month="July" year="2020"/>

    <abstract>
      <t>The BGP Monitoring Protocol (BMP) provides an interface for obtaining
      BGP path information. BGP Path Information is conveyed within BMP Route
      Monitoring (RM) messages. This document proposes an extension to BMP to
      convey additional path information that is not already encapsulated in
      the BGP Update PDU, e.g., BPG path status. This extension makes use of
      the TLV mechanims described in <xref
      target="I-D.grow-bmp-tlv">draft-grow-bmp-tlv</xref>.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119">RFC 2119</xref> <xref target="RFC8174">RFC
      8174</xref> when, and only when, they appear in all capitals, as shown
      here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>BGP Monitoring Protocol (BMP) <xref target="RFC7854">RFC7854</xref>
      is used to monitor BGP sessions. Additional information is allowed to be
      carried in the format of TLV with the BMP Initiation, Peer Up, and
      Termination Messages <xref target="RFC7854">RFC7854</xref> <xref
      target="I-D.ietf-grow-bmp-peer-up">draft-ietf-grow-bmp-peer-up</xref>.
      <xref target="I-D.grow-bmp-tlv">draft-grow-bmp-tlv</xref> provides the
      capability of conveying optional data in TLV format in BMP Route
      Monitoring (RM) and Peer Down Messages, and such TLV types are to be
      defined for each application. This document defines the Path Information
      TLV, making use of the TLV mechanism defined for BMP RM Message <xref
      target="I-D.grow-bmp-tlv">draft-grow-bmp-tlv</xref>. The Path
      Information TLV is used to describe the path information, e.g., path
      status (best, best-external), out interface, and so on. Specific path
      information can be defined as sub-TLVs encapsulated within the Path
      Information TLV.</t>
    </section>

    <section title="Path Information TLV for the RM Message">
      <t>The Path Information TLV is defined as follows.</t>

      <t><figure>
          <artwork><![CDATA[ 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
+-------------------------------+-------------------------------+
|        Type (2 octets)        |       Length (2 octets)       |
+---------------------------------------------------------------+
|        Count (2 octets)       |
+-------------------------------+-------------------------------+
|                   Path Information value(variable)            |
+---------------------------------------------------------------+

                Figure 1: Path Information TLV ]]></artwork>
        </figure><list style="symbols">
          <t>Type = TBD1 (2 Octets): indicates that it's the Path Information
          TLV.</t>

          <t>Length (2 Octets): indicates the length of the value field of the
          Path Information TLV.</t>

          <t>Count (2 Octets): indicates the number of sub TLVs followed in
          the Path Information Value field.</t>

          <t>Path Information value (Variable): indicates the value of the
          Path Informtion TLV, which consists of one or multiple sub TLVs.</t>
        </list></t>

      <t>Each RM Message allows at most one Path Information TLV. As stated in
      Appendix F.1 of <xref target="RFC4271">RFC4271</xref>, multiple address
      prefixes (i.e., NLRI) with the same path attributes are allowed to be
      specified in one BGP message. However, such multiple prefixes may have
      different path information. Thus, to distinguish the sub-TLV for
      different prefixes, the order of the sub-TLVs MUST be in accordance with
      the prefix order encapsulated in the Update PDU.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests that IANA assign the following new parameters
      to the BMP parameters name space.</t>

      <t>Type = TBD1 (2 Octets): indicates that it's the Path Information
      TLV.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>It is not believed that this document adds any additional security
      considerations.</t>
    </section>
  </middle>

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

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

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

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

      <?rfc include='reference.I-D.grow-bmp-tlv'?>

      <?rfc include='reference.I-D.ietf-grow-bmp-peer-up'?>
    </references>
  </back>
</rfc>