<?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-li-idr-bgp-ls-sbfd-extensions-01"
     ipr="trust200902">
  <front>
    <title abbrev="BGP-LS Extensions for S-BFD">BGP Link-State Extensions for
    Seamless BFD</title>

    <author fullname="Zhenbin Li" initials="Z. " surname="Li">
      <organization>Huawei</organization>

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

          <city>Beijing</city>

          <code>100095</code>

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

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

    <author fullname="Sam Aldrin" initials=" " surname="Sam aldrin">
      <organization>Google, Inc</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Jeff Tantsura" initials=" J." surname="Tantsura">
      <organization>Individual</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Greg Mirsky" initials=" G." surname="Mirsky">
      <organization>ZTE Corp.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>gregimirsky@gmail.com</email>
      </address>
    </author>

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

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

          <city>Beijing</city>

          <code>100095</code>

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

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

    <date day="25" month="April" year="2017"/>

    <abstract>
      <t><xref target="RFC7880"/> defines a simplified mechanism to use
      Bidirectional Forwarding Detection (BFD) with large portions of
      negotiation aspects eliminated, thus providing benefits such as quick
      provisioning as well as improved control and flexibility to network
      nodes initiating the path monitoring. The link-state routing protocols
      (IS-IS, OSPF and OSPFv3) have been extended to advertise the Seamless
      BFD (S-BFD) Discriminators.</t>

      <t>This draft defines extensions to the BGP Link-state address-family to
      carry the S-BFD Discriminators information via BGP.</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><xref target="RFC7880"/> defines a simplified mechanism to use
      Bidirectional Forwarding Detection (BFD)<xref target="RFC5880"/> with
      large portions of negotiation aspects eliminated, thus providing
      benefits such as quick provisioning as well as improved control and
      flexibility to network nodes initiating the path monitoring.</t>

      <t><xref target="RFC7883"/> defines a mean of advertising one or more
      S-BFD Discriminators using the IS-IS Router Capability TLV. <xref
      target="RFC7884"/> defines a new OSPF Router Information (RI) TLV that
      allows OSPF routers to flood the S-BFD discriminator values associated
      with a target network identifier. This mechanism is applicable to both
      OSPFv2 and OSPFv3.</t>

      <t>The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been
      extended to advertise the S-BFD Discriminators. But flooding based
      propagation of the S-BFD Discriminators using IGPs is limited by the
      perimeter of the IGP domain. For advertising the S-BFD Discriminators
      which span across IGP domains (e.g. multiple ASes), the Border Gateway
      Protocol (BGP) is better suited as its propagation perimeter is not
      limited like the IGPs.</t>

      <t>This draft defines extensions to the BGP Link-state address-family to
      carry the S-BFD Discriminators information via BGP.</t>
    </section>

    <section title="Terminology">
      <t>This memo makes use of the terms defined in <xref
      target="RFC7880"/>.</t>
    </section>

    <section title="Problem and Requirement">
      <t>Seamless MPLS <xref target="I-D.ietf-mpls-seamless-mpls"/> extends
      the core domain and integrates aggregation and access domains into a
      single MPLS domain. In a large network, the core and aggregation
      networks can be organized as different autonomous systems. Although the
      core and aggregation networks are segmented into different autonomous
      systems, but an E2E LSP will be created using hierarchical-labeled BGP
      LSPs based on iBGP-labeled unicast within each AS, and eBGP-labeled
      unicast to extend the LSP across AS boundaries. Meanwhile, the customer
      will see only two service-end points in the Seamless MPLS network. In
      order to detect the possible failure quickly and protect the
      network/trigger re-routing, BFD MAY be used for the Service Layer (e.g.
      for MPLS VPNs, PW ) and the Transport Layer, so the need arises that the
      BFD session has to span across AS domain.</t>

      <t>The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been
      extended to advertise the S-BFD Discriminators. But flooding based
      propagation of the S-BFD Discriminators using IGPs is limited by the
      perimeter of the IGP domain. For advertising the S-BFD Discriminators
      which span across IGP domains (e.g. multiple ASes), the Border Gateway
      Protocol (BGP) is better suited as its propagation perimeter is not
      limited like the IGPs. This draft defines extensions requirement to the
      BGP Link-state address-family to carry the S-BFD Discriminators
      information via BGP.</t>
    </section>

    <section title="BGP-LS Extensions for S-BFD Discriminators Exchanging">
      <t>The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. The
      corresponding BGP-LS attribute is a node attribute, a link attribute or
      a prefix attribute. BGP-LS <xref target="RFC7752"/> defines the TLVs
      that map link-state information to BGP-LS NLRI and BGP-LS attribute.
      This document adds additional BGP- LS attribute TLVs to encode the S-BFD
      Discriminators information.</t>

      <t><xref target="RFC7880"/> defines the following TLVs to encode the
      S-BFD Discriminators information.</t>

      <t>The ISIS Router CAPABILITY TLV as defined in <xref target="RFC4971"/>
      will be used to advertise S-BFD discriminators. A new Sub-TLV is defined
      as described below. S-BFD Discriminators Sub-TLV is formatted as
      specified in <xref target="RFC5305"/>.</t>

      <figure>
        <artwork align="center"><![CDATA[
                                 No. of octets     
+-----------------------------+                    
| Type (20)                   |     1              
+-----------------------------+                    
| Length (multiple of 4)      |     1              
+-----------------------------+                    
| Discriminator Value(s)      |     4/Discriminator
:                             :                    
+-----------------------------+                    
Figure 1: S-BFD Discriminators Sub-TLV for ISIS

]]></artwork>
      </figure>

      <t>Inclusion of the S-BFD Discriminators sub-TLV in a Router Capability
      TLV is optional. Multiple S-BFD Discriminators sub-TLVs MAY be
      advertised by an IS.</t>

      <t><xref target="RFC7884"/> defines the following TLVs to encode the
      S-BFD Discriminators information. The format of the S-BFD Discriminator
      TLV is as follows:</t>

      <figure>
        <artwork align="center"><![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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Discriminator 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Discriminator 2 (Optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Discriminator n (Optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 2: S-BFD Discriminators TLV for OSPF

]]></artwork>
      </figure>

      <t>Type - S-BFD Discriminator TLV Type (11)</t>

      <t>Length - Total length of the discriminator (Value field) in octets,
      not including the optional padding. The Length is a multiple of 4
      octets, and consequently specifies how many Discriminators are included
      in the TLV.</t>

      <t>Value - S-BFD network target discriminator value or values.</t>

      <t>Routers that do not recognize the S-BFD Discriminator TLV Type MUST
      ignore the TLV. S-BFD discriminator is associated with the BFD Target
      Identifier type, which allows de-multiplexing to a specific task or
      service.</t>

      <t/>

      <t>These TLVs are mapped to BGP-LS attribute TLVs in the following way.
      The new information in the Link-State NLRIs and attributes is encoded in
      Type/Length/Value triplets.</t>

      <figure>
        <artwork align="center"><![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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                        Value (variable)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 3: BGP-LS TLV format

]]></artwork>
      </figure>

      <t>The 2 octet Type field values are defined in Table 1. The next 2
      octet Length field encodes length of the rest of the TLV. The Value
      portion of the TLV is variable and is equal to the corresponding Value
      portion of the TLV defined in <xref target="RFC7883"/> and <xref
      target="RFC7884"/>.</t>

      <t>The following 'Node Attribute' TLVs are defined:</t>

      <figure>
        <artwork align="center"><![CDATA[
+---------------+-------------------------+----------+--------------+
|    TLV Code   | Description             | Length   |    ISIS/OSPF |
|     Point     |                         |          |  TLV/Sub-TLV |
+---------------+-------------------------+----------+--------------+
|      TBD      | S-BFD Discriminators    | variable |          TBD |
|      ...      | ...                     | ...      |          ... |
+---------------+-------------------------+----------+--------------+
                        Table 1: Node Attribute TLVs

]]></artwork>
      </figure>

      <t>These TLVs can ONLY be added to the Node Attribute associated with
      the Node NLRI that originates the corresponding S-BFD Discriminator
      TLV.</t>

      <t/>
    </section>

    <section title="Operations">
      <t>Existing BGP and BGP-LS operational procedures apply. No new
      operation procedures are defined in this document.</t>

      <t/>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests assigning code-points from the registry for
      BGP-LS attribute TLVs based on table Table 1.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Procedures and protocol extensions defined in this document do not
      affect the BGP security model. See <xref target="RFC6952"/> for
      details.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Nan Wu for his contributions to this
      work.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-mpls-seamless-mpls'?>
    </references>
  </back>
</rfc>
