One document matched: draft-akiya-bfd-seamless-ip-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->


<rfc category="std" docName="draft-akiya-bfd-seamless-ip-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Seamless BFD for IP">
	Seamless Bidirectional Forwarding Detection (BFD) for IP
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->

    <author fullname="Nobo Akiya" initials="N."
            surname="Akiya">
      <organization>Cisco Systems</organization>
      <address>
        <email>nobo@cisco.com</email>
      </address>
    </author>

    <author fullname="Carlos Pignataro" initials="C."
            surname="Pignataro">
      <organization>Cisco Systems</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>

    <author fullname="Dave Ward" initials="D."
            surname="Ward">
      <organization>Cisco Systems</organization>
      <address>
        <email>wardd@cisco.com</email>
      </address>
    </author>

    <date day="7" month="June" year="2013" />

    <area>BFD Working Group</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
    IETF is fine for individual submissions.  
	If this element is not present, the default is "Network Working Group",
    which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>BFD</keyword>
    <keyword>seamless BFD</keyword>
    <keyword>negotiation free</keyword>
    <keyword>label verification</keyword>
    <keyword>segment routing</keyword>
    <keyword>IP</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
    	<t>This specification defines procedures to use Seamless Bidirectional Forwarding Detection (BFD) in IP and IP signalled MPLS environments.</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>One application for Seamless Bidrectional Forwarding Detection (BFD) [I-D.akiya-bfd-seamless-base] is to perform full and partial reachability validations on IP and IP signalled MPLS environments.</t>

<t>This specification defines procedures to use Seamless BFD in IP and IP signalled MPLS environments.</t>

    </section>

    <section title="BFD Target Identifier Type">

<t>BFD target identifier type of value 1 is used for IPv4 addresses and router IDs. This identifier type will cover Seamless BFD in following scenarios:

<list style="symbols">
<t>BFD control packets IPv4 routed.</t>
<t>BFD control packets IPv6 routed.</t>
<t>BFD control packets label switched in IPv4 signaled LSP.</t>
<t>BFD control packets label switched in IPv6 signaled LSP.</t>
</list>

Not all IPv6 aspects are covered by this specification, and details are clarified in <xref target="Res_BFD_Dis" />.</t>

    </section>

    <section title="Reserved BFD Discriminators" anchor="Res_BFD_Dis">

<t>With IPv4 based BFD, BFD target identifier type 1 is used. BFD discriminator values corresponding to all or subset of local IPv4 addresses are to be reserved. IPv4 addresses are used as BFD discriminators. Corresponding BFD discriminators MUST be reserved and those BFD discriminators MUST NOT be used for other BFD sessions.</t>

<t>Example:
<list style="symbols">
<t>BFD Target Identifier Type 1: IPv4 address 3.3.2.1 maps to BFD discriminator 0x03030201.</t>
</list>
</t>

<t>With IPv6 based BFD, BFD target identifier type 1 is used. BFD discriminator values corresponding to all or subset of local IGP Router IDs are to be reserved. These router IDs are used as BFD discriminators. With OSPFv3, employed 32 bit router IDs are used. Corresponding BFD discriminators MUST be reserved and those BFD discriminators MUST NOT be used for other BFD sessions. ISIS is not included as part of this identifier type, and is outside the scope of this document.</t>

<t>Example:
<list style="symbols">
<t>BFD Target Identifier Type 1: Router-ID 3.3.4.5 maps to BFD discriminator 0x03030405.</t>
</list>
</t>

<t>Note that it is acceptable for an IPv4 address and a router-ID to collide, mapping into a same BFD discriminator value. There will not be an issue as long as colliding BFD discriminator value is reserved for the Seamless BFD purpose.</t>

    </section>

    <section title="BFD Target Identifier Table">

<t>With IP identifier type, only locally reserved BFD discriminators and corresponding information are to be in this table. No inter-node communications are needed to exchange BFD discriminator and BFD target identifier mappings.</t>

    </section>

    <section title="Full Reachability Validations">

<section title="Initiator Behavior">

<t>Any IP network node can attempt to perform a full reachability validation to any BFD target identifier of type 1 (IPv4 address or router-ID) on other network nodes, as long as destination BFD target identifier is provisioned to use this mechanism. Transmitted BFD control packet by the initiator is to have "your discriminator" corresponding to destination BFD target identifier of type 1.</t>

<t>Initiator is to use following procedures to construct BFD control packets to perform IP full reachability validations on BFD packets that are IP routed:
<list style="symbols"><?rfc subcompact="yes" ?>
<t>MUST set "your discriminator" to target IPv4 address or target router-ID.</t>
<t>If packet is to be explicitly label switched, then explicit label switching packet format described in [I-D.akiya-bfd-seamless-base] MUST be used. Otherwise IP routing packet format described in [I-D.akiya-bfd-seamless-base] MUST be used.</t>
</list><?rfc subcompact="no" ?>
</t>

</section>

<section title="Responder Behavior">

<t>To respond to received BFD control packet which was targeted to local BFD target identifier of type 1 (IP ddress or router-ID), response BFD control packet is targeted to IP address taken from received "source IP address". Responder MUST validate obtained IP address is in valid format (ex: not Martian address). Responder MUST consult local routing table to ensure obtained IP address is reachable.</t>

</section>

    </section>

    <section title="Partial Reachability Validations">

<t>Procedures described in [I-D.akiya-bfd-seamless-base] applies.</t>

    </section>

    <section title="MPLS Label Verifications" anchor="MPLS_label_verification">

<t>MPLS label verification mechanism is applicable to those IP based BFD which use explicit label switching techniques. However, details of what responder embeds in the lower 23 bits of localhost address, and how initiator determines correctness of label programming is outside the scope of this document.</t>

    </section>

    <section title="Provisiong Active IP Sessions" anchor="Provision_IP">

<t>Active IP BFD sessions, single-hop, multi-hop or MPLS can be instantiated on any network node using this mechanism to any IPv4 target addresses and OSPFv3 router IDs using this mechanism. This style of usage is particularly useful only if one side is required to perform full reachability validations (ex: static route, uni-directional tunnel). This style of usage is also particularly useful to perform validations and verifications on just subset of LSPs (ex: inter-AS, injection of partial BFD reachability validation packet on IPv4 RSVP LSP nodes).</t>

    </section>

    <section anchor="Security" title="Security Considerations">

<t>Same security considerations as <xref target="RFC5880" />, <xref target="RFC5881" />, <xref target="RFC5883" />, <xref target="RFC5884" />, <xref target="RFC5885" /> and [I-D.akiya-bfd-seamless-base] apply to this document.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
     <t>None</t>
    </section>

    <section title="Acknowledgements">

	<t>Authors would like to thank Marc Binderberger from Cisco Systems for providing valuable comments.</t>

    </section>

    <section title="Contributing Authors">

    <t>Tarek Saad
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: tsaad@cisco.com</t>

	<t>Siva Sivabalan
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: msiva@cisco.com</t>

	<t>Nagendra Kumar
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: naikumar@cisco.com</t>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
	  <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.5880"?>
	  <?rfc include="reference.RFC.5881"?>
	  <?rfc include="reference.RFC.5883"?>
	  <?rfc include="reference.RFC.5884"?>
       
    </references>
    
    <references title="Informative References">
	  <?rfc include="reference.RFC.2827"?>
       <?rfc include="reference.RFC.4379"?>
	  <?rfc include="reference.RFC.5885"?>
	  <?rfc include="reference.RFC.6428"?>
       <?rfc include="reference.I-D.ietf-bfd-on-lags"?>
       <?rfc include="reference.I-D.previdi-filsfils-isis-segment-routing"?>
    </references>

    <!-- Change Log
v00-a 2013-05-20 Nobo: Initial version
v00-b 2013-05-24 Nobo: Included comments from Carlos/Nagendra
v00-c 2013-05-27 Nobo: Incorporated comments from Marc
    -->
  </back>
</rfc>