One document matched: draft-ginsberg-isis-prefix-attributes-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-ginsberg-isis-prefix-attributes-00.txt"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="isis-prefix-attributes">IS-IS Prefix Attributes for
    Extended IP and IPv6 Reachability</title>

    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>510 McCarthy Blvd.</street>

          <city>Milpitas</city>

          <code>95035</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>ginsberg@cisco.com</email>
      </address>
    </author>

    <author fullname="Bruno Decraene" initials="B" surname="Decraene">
      <organization>Orange</organization>

      <address>
        <postal>
          <street>38 rue du General Leclerc</street>

          <city>MIssy Moulineaux cedex 9</city>

          <code>92794</code>

          <region/>

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

        <email>bruno.decraene@orange.com</email>
      </address>
    </author>

    <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <region/>

          <country/>
        </postal>

        <email>cfilsfils@cisco.com</email>
      </address>
    </author>

    <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization>Orange Business Service</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>stephane.litkowski@orange.com</email>
      </address>
    </author>

    <author fullname="Stefano Previdi" initials="S" surname="Previdi">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Via Del Serafico 200</street>

          <city>Rome</city>

          <code>0144</code>

          <country>Italy</country>
        </postal>

        <email>sprevidi@cisco.com</email>
      </address>
    </author>

    <date day="06" month="October" year="2014"/>

    <area>Routing Area</area>

    <workgroup>Networking Working Group</workgroup>

    <keyword>Sample</keyword>

    <abstract>
      <t>This document introduces new sub-TLVs to support advertisement of
      prefix attribute flags and the source router id of the router which
      originated a prefix advertisement.</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 RFC 2119 [RFC2119].</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>There are existing use cases in which knowing additional attributes
      of a prefix is useful. For example, it is useful to know whether an
      advertised prefix is directly connected to the advertising router or
      not. In the case of [SR] knowing whether a prefix is directly connected
      or not determines what action should be taken as regards processing of
      labels associated with an incoming packet. Current formats of the
      Extended Reachability TLVs for both IP and IPv6 are fixed and do not
      allow the introduction of additional flags without backwards
      compatibility issues. Therefore a new sub-TLV is introduced which allows
      for the advertisement of attribute flags associated with prefix
      advertisements.</t>

      <t>It is also useful to know the source of a prefix advertisement when
      the advertisement has been leaked to another level. Therefore a new
      sub-TLV is introduced to advertise the router-id of the originator of a
      prefix advertisement.</t>
    </section>

    <section title="New sub-TLVs for Extended Reachability TLVs">
      <t>The following new sub-TLVs are introduced:</t>

      <t><list style="symbols">
          <t>IPv4/IPv6 Extended Reachability Attributes</t>

          <t>IPv4 Source Router ID</t>

          <t>IPv6 Source Router ID</t>
        </list> All sub-TLVs are applicable to TLVs 135, 235, 236, and/or
      237.</t>

      <section title="IPv4/IPv6 Extended Reachability Attribute Flags">
        <t>This sub-TLV supports the advertisement of additional flags
        associated with a given prefix advertisement. When a prefix
        advertisement is leaked from one level to another (upwards or
        downwards) the state of a given flag is either preserved or set to 0.
        The behavior of each flag is explicitly defined below.</t>

        <t>All flags are applicable to TLVs 135, 235, 236, 237 unless
        otherwise stated.</t>

        <t><figure>
            <artwork><![CDATA[  Prefix Attribute Flags
  Type:   4 (suggested - to be assigned by IANA)
  Length: Number of octets to follow
  Value

       (Length * 8) bits. 
 
    0 1 2 3 4 5 6 7...
   +-+-+-+-+-+-+-+-+...
   |X|R|N|          ...
   +-+-+-+-+-+-+-+-+...

  Bits are defined/sent starting with Bit #0 defined below. Additional
  bit definitions which may be defined in the future SHOULD be assigned
  in ascending bit order so as to minimize the number of bits which
  will need to be transmitted.

  X-Flag: External Prefix Flag (Bit 0)
      Set if the prefix has been redistributed from another protocol.
      This includes the case where multiple virtual routers are
      supported and the source of the redistributed prefix is another
      IS-IS instance.
      The flag is preserved when leaked between levels.
      In TLVs 236 and 237 this flag SHOULD always be sent as 0 and 
      MUST be ignored on receipt. This is because there is an existing 
      X flag defined in the fixed format of these TLVs as specified in 
      [RFC5308] and [RFC5120].

  R-Flag: Re-advertisement Flag (Bit 1)
      Set when the prefix has been leaked from one level to another
      (upwards or downwards).

  N-flag: Node Flag (Bit 2)
      Set when the prefix identifies the advertising router i.e., the
      prefix is a host prefix advertising a globally reachable address
      typically associated with a loopback address.
      The advertising router MAY choose to NOT set this flag even when 
      the above conditions are met.
      If the flag is set and the prefix length is NOT a host prefix
      (/32 for IPV4, /128 for IPv6) then the flag MUST be ignored.
      The flag is preserved when leaked between levels.

]]></artwork>
          </figure></t>
      </section>

      <section title="IPv4/IPv6 Source Router ID">
        <t>When a reachability advertisement is leaked from one level to
        another, the source of the original advertisement is unknown. In cases
        where the advertisement is an identifier for the advertising router
        (e.g., N-flag set in the Extended Reachability Attribute sub-TLV as
        described in the previous section) it may be useful for other routers
        to know the source of the advertisement. The sub-TLVs defined below
        provide this information.</t>

        <t><figure>
            <artwork><![CDATA[  IPv4 Source Router ID
  Type:   11 (suggested - to be assigned by IANA)
  Length: 4
  Value: IPv4 Router ID of the source of the advertisement

  Inclusion of this TLV is optional and MAY occur in TLVs 
  135, 235, 236, or 237.

  If present the sub-TLV MUST be included when the prefix
  advertisement is leaked to another level.

  IPv6 Source Router ID
  Type:   12 (suggested - to be assigned by IANA)
  Length: 16
  Value: IPv6 Router ID of the source of the advertisement

  Inclusion of this TLV is optional and MAY occur in TLVs 
  135, 235, 236, or 237.

  If present the sub-TLV MUST be included when the prefix
  advertisement is leaked to another level.

]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document adds the following new sub-TLVs to the registry of
      sub-TLVs for TLVs 135, 235, 236, 237.</t>

      <t>Value: 4 (suggested - to be assigned by IANA)</t>

      <t>Name: Prefix Attribute Flags</t>

      <t>Value: 11 (suggested - to be assigned by IANA)</t>

      <t>Name: IPv4 Source Router ID</t>

      <t>Value: 12 (suggested - to be assigned by IANA)</t>

      <t>Name: IPv6 Source Router ID</t>

      <t>This document also introduces a new registry for bit values in the
      Prefix Attribute Flags sub-TLV. Registration policy is Expert Review as
      defined in [RFC5226]. Defined values are:</t>

      <t><figure>
          <artwork><![CDATA[     Bit #   Name
     -----   ------------------------
     0       External Prefix Flag
     1       Re-advertisement Flag
     2       Node Flag

]]></artwork>
        </figure></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>None.</t>
    </section>

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

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

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

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

      <?rfc include='reference.RFC.5226'?>
    </references>

    <references title="Informational References">
      <reference anchor="SR">
        <front>
          <title>IS-IS Extensions for Segment Routing,
          draft-ietf-isis-segment-routing-extensions-02(work in
          progress)</title>

          <author fullname="Previdi S., et al,"/>

          <date month="June" year="2014"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>