<?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-mirsky-mpls-bfd-bootstrap-clarify-00" ipr="trust200902" updates="5884">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <front>
    <title abbrev="Clarify Bootstrapping BFD over MPLS LSP">Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP</title>

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

      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    
  <author fullname="Yanhua Zhao" initials="Y." surname="Zhao">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>          
          <city/>          
          <region/>  
          <code/>
          <country/>
        </postal>
        <phone/>
        <email>zhao.yanhua3@zte.com.cn</email>
      </address>
    </author>

    <date day="18" month="October" year="2017"/>

    <area>Routing</area>

    <workgroup>MPLS Working Group</workgroup>

    <keyword>Internet-Draft</keyword>
   
   <keyword>BFD</keyword>
   
   <keyword>LSP Ping</keyword>

    <abstract>
      <t>
      This document, if approved, updates RFC 5884 by clarifying 
      procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD)
over MPLS Label Switch Path.
      </t>
    </abstract>
        </front>
  
  <middle>

    <section anchor="intro-section" title="Introduction">
      <t>
      <xref target="RFC5884"/> defines how LSP Ping <xref target="RFC8029"/>
      uses BFD Discriminator TLV to bootstrap Bidirectional Forwarding Detection (BFD) session
      over MPLS Label Switch Path (LSP). Implementation and operational experiences suggest
      that two aspects of using LSP ping to bootstrap BFD session can benefit from clarification. 
      This document updates <xref target="RFC5884"/> in use of Return mode field in MPLS LSP
      echo request message and use of BFD Discriminator TLV in MPLS LSP echo reply.
      </t>

    </section>
    
      <section title="Conventions used in this document">
     <section title="Terminology">     
     <t>MPLS:       Multiprotocol Label Switching</t>
     <t>LSP:        Label Switched Path</t>
     <t>BFD:        Bidirectional Forwarding Detection</t>
     </section>
     
     <section 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"/> <xref target="RFC8174"/> 
   when, and only when, they appear in all capitals, as shown here.
             </t>
    </section>
    </section>

    <section anchor="return-mode" title="Use of Return Mode Field">
      <t>
      <xref target="RFC5884"/> does not define the value to be used for the Return mode field <xref target="RFC8029"/>
      when LSP ping is used to bootstrap a BFD session of MPLS LSP. When LSP echo request is being used to detect defects
      in MPLS data plane and verify consistency between the control plane and the data plane echo reply is needed to confirm
      the correct state, provide the positive acknowledgment. But when LSP echo request is being used to bootstrap BFD session,
      then the positive acknowledgement, according to <xref target="RFC5884"/> is provided by the egress transmitting BFD control message.
      Thus LSP echo reply is not required to bootstrap BFD session and hence the Return mode field in echo request message
      SHOULD be set to 1 (Do not reply) <xref target="RFC8029"/> when LSP echo request used to bootstrap BFD session.
      </t>
</section>

      <section anchor="bfd-disc-echo-reply" title="Use of BFD Discriminator TLV in LSP Echo Reply">
        <t>
<xref target="RFC5884"/> in section 6 defines that echo reply  by the egress LSR to BFD bootstrapping echo request MAY include
BFD Discriminator TLV with locally assigned discriminator value for the BFD session. But the <xref target="RFC5884"/> does not define
how the ingress LSR may use the returned value. From practical point, as discussed in <xref target="return-mode"/>, the returned value is
not useful since the egress is required to send the BFD control message right after successfully validating the FEC and before sending echo reply
message. Secondly, identifying the corresponding BFD session at ingress without returning its discriminator presents unnecessary challenge for
the implementation. Thus the egress LSR SHOULD NOT include BFD Discriminator TLV if sending echo reply to BFD bootstrapping echo request.
        </t>

      </section>

    <section anchor="IANA" title="IANA Considerations">
<t>
This document does not require any action by IANA. This section may be removed.
</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
      This document does not introduce new security aspects but inherits all security considerations
      from <xref target="RFC5880"/>, <xref target="RFC5884"/>, <xref target="RFC8029"/>.
      </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
      TBA
      </t>
    </section>
  </middle>

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

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

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

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

    </references>

<!--
    <references title="Informative References">
      
    </references>
-->
  </back>
</rfc>
