One document matched: draft-ietf-ospf-sbfd-discriminator-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-ietf-ospf-sbfd-discriminator-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="OSPF-extensions">
	OSPF extensions to advertise S-BFD Target Discriminator
    </title>

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

    <author fullname="Manav Bhatia" initials="M."
            surname="Bhatia">
      <organization>Ionos Networks</organization>
      <address>
        <email>manav@ionosnetworks.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="Sam Aldrin" initials="S."
            surname="Aldrin">
      <organization>Huawei Technologies </organization>
      <address>
        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Trilok Ranganath" initials="T."
            surname="Ranganath">
      <organization>Alcatel-Lucent</organization>
      <address>
        <email>trilok.ranganatha@alcatel-lucent.com</email>
      </address>
    </author>

     <date />

    <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 document 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>
    </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" anchor="Intro">

<t> 
Seamless Bidirectional Forwarding Detection (S-BFD), specified in 
<xref target="I-D.ietf-bfd-seamless-base" />,
is a simplified mechanism for using BFD with many negotiations eliminated.
This is achieved by using unique network-wide discriminators to identify
the Network Targets (e.g., IP addresses).

   These S-BFD discriminators can be advertised by the IGPs, and this document concerns itself with OSPF.

   Specifically, this document defines a new TLV (named the S-BFD Discriminator TLV) to be carried within the OSPF Router 
    Information LSA (<xref target="RFC4970" />).
</t>
    <section title="Relationship between OSPF and S-BFD">
<t>
This document, implicitly, defines a relationship between OSPF and S-BFD.
S-BFD assigns one or more Discriminators to each S-BFD reflector node.
OSPF, in turn, learns about these from S-BFD, and floods them in the newly
defined TLV. After this information is flooded, it is stored in all the OSPF
nodes such that S-BFD initiators can map out target nodes to target Discriminators, and can therefore construct the S-BFD probe.
</t>
    </section>
    </section>

    <section title="Implementation">
 
<t>This extension makes use of the Router Information (RI) Opaque LSA,
   defined in <xref target="RFC4970" /> , for both OSPFv2 <xref target="RFC2328" />
   and OSPFv3 <xref target="RFC5340" />, by defining a new
   OSPF Router Information (RI) TLV: the S-BFD Discriminator TLV.
</t>
<t>
   The S-BFD Discriminator TLV is OPTIONAL. Upon receipt
   of the TLV, a router may decide to ignore this TLV or install the
   S-BFD discriminator in BFD Target Identifier Table.
</t>

    <section title="S-BFD Discriminator TLV">

<t> The format of the S-BFD Discriminator TLV is as follows: </t>

<figure align="left"><preamble></preamble><artwork align="left">
     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)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>

 <t> Type - S-BFD Discriminator TLV Type  </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, 
   that allows demultiplexing to a specific task or service.</t>
</section>

 
    <section title="Flooding Scope">

<t>
The flooding scope for S-BFD Discriminator information advertised through OSPF can be
   limited to one or more OSPF areas, or can be
   extended across the entire OSPF routing domain.
</t>

<t> Note that the S-BFD session may be required to pan multiple areas, in which case the
   flooding scope may comprise these areas.  This could be the case for
   an ABR, for instance, advertising the S-BFD Discriminator information within the
   backbone area and/or a subset of its attached IGP area(s).
	</t>

<t>The S-BFD Discriminator  TLV is advertised within OSPFv2 Router Information LSAs
   (Opaque type of 4 and Opaque ID of 0) or OSPFv3 Router Information
   LSAs (function code of 12), which are defined in <xref target="RFC4970" />.  As such,
   elements of procedure are inherited from those defined in <xref target="RFC4970" />.
</t>

<t>  In OSPFv2, the flooding scope is controlled by the opaque LSA type
   (as defined in <xref target="RFC5250" />) and in OSPFv3, by the S1/S2 bits (as
   defined in <xref target="RFC5340" />).  If the flooding scope is area local, then the
   S-BFD Discriminator  TLV MUST be carried within an OSPFv2 type 10 router information
   LSA or an OSPFV3 Router Information LSA with the S1 bit set and the
   S2 bit clear.  If the flooding scope is the entire IGP domain, then
   the S-BFD Discriminator  TLV MUST be carried within an OSPFv2 type 11 Router
   Information LSA or OSPFv3 Router Information LSA with the S1 bit
   clear and the S2 bit set.  
</t>

<t>   When the S-BFD Reflector is deactivated, the OSPF speaker advertising
   this S-BFD Discriminator MUST originate a new Router Information LSA that no longer
   includes the corresponding S-BFD Discriminator TLV, provided there are other TLVs in
   the LSA.  If there are no other TLVs in the LSA, it MUST either send
   an empty Router Information LSA or purge it by prematurely ageing it.
</t>

<t> For intra-area reachability, the S-BFD Discriminator TLV information regarding a specific target identifier is only considered
   current and useable when the router advertising this information is
   itself reachable via OSPF calculated paths in the same area of the
   LSA in which the S-BFD Discriminator TLV appears.

In the case of domain-wide flooding, i.e., where the originator is sitting in a remote area, the mechanism described in section 5 of <xref target="RFC5250" /> should be used.
</t>

<t> A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF
   computation at a receiving router.
</t>
</section>
</section>
    <section anchor="backward" title="Backward Compatibility">
<t>  The S-BFD Discriminator TLV defined in this document does not introduce any
   interoperability issues. </t>

  <t> A router not supporting the S-BFD Discriminator TLV will just silently ignore the
   TLV as specified in <xref target="RFC4970" />.
</t>
	</section>
    <section anchor="Security" title="Security Considerations">

<t> This document defines OSPF extensions to distribute the S-BFD discriminator within an
   administrative domain.  Hence the security of the S-BFD discriminator distribution
   relies on the security of OSPF.
</t>
<t>
OSPF provides no encryption mechanism for protecting the privacy of
   LSAs and, in particular, the privacy of the S-BFD discriminator  advertisement
   information. This however is not a concern as there isn't any need to hide the 
 discriminator value that can be used to reach the Reflectors.
</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
<t>IANA has defined a registry for TLVs carried in the Router
   Information LSA defined in <xref target="RFC4970" />.  
  IANA needs to assign a new TLV
   codepoint for the S-BFD Discriminator TLV carried within the Router Information LSA.

<figure align="left"><preamble></preamble><artwork align="left">
     Value      TLV Name                 Reference
     -----      --------                 ----------
     TBD        S-BFD                    (this document)
                Discriminator
</artwork></figure>
      </t>
    </section>

    <section title="Acknowledgements">

<t>
The authors would like to thank Nobo Akiya, Les Ginsberg, Mach Chen and Peter Psenak for insightful comments and useful suggestions.
</t>

    </section>
  </middle>

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

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

    <references title="Normative References">
	  <?rfc include="reference.I-D.ietf-bfd-seamless-base"?>
	  <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.2328"?>
	  <?rfc include="reference.RFC.5340"?>
	  <?rfc include="reference.RFC.4970"?>
      
    </references>
    
    <references title="Informative References">
	  <?rfc include="reference.RFC.5250"?>
    </references>

  </back>
</rfc>