<?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" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?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-xu-bess-l3vpn-prefix-orf-00"
     ipr="trust200902">
  <front>
    <title abbrev="">L3VPN Address Prefix Based Outbound Route Filter for
    BGP-4</title>

    <author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
      <organization>Huawei</organization>

      <address>
        <!--
       <postal>
         <street></street>
-->

        <!-- Reorder these if your country does things differently -->

        <!--
         <city>Soham</city>

         <region></region>

         <code></code>

         <country>UK</country>
       </postal>

       <phone>+44 7889 488 335</phone>
-->

        <email>xuxiaohu@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!--

-->

    <date day="" month="" year="2015"/>

    <abstract>
      <t>This document defines a new Outbound Router Filter (ORF) type for
      BGP, refered to as "L3VPN Address Prefix Outbound Route Filter", that
      can be used to perform L3VPN address-prefix-based route filtering. This
      ORF-type supports prefix-length- or range-based matching,
      wild-card-based address prefix matching, as well as the exact address
      prefix matching for L3VPN address families. The L3VPN Address Prefix ORF
      is applicable in the Virtual Subnet context.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Outbound Route Filtering (ORF) Capability defined in <xref
      target="RFC5291"/> provides a mechanism for a BGP speaker to send to its
      BGP peer a set of ORFs that can be used by its peer to filter its
      outbound routing updates to the speaker. The Address Prefix ORF defined
      in <xref target="RFC5292"/> is used to perform address-prefix-based
      route filtering. However, the Address Prefix ORF is not much suitable
      for L3VPN <xref target="RFC4364"/> route filting since there is no
      Route-Target (RT) field contained in the Address Prefix ORF entry.</t>

      <t>This document builds on <xref target="RFC5292"/> and defines a new
      ORF-type for BGP, refered to as "L3VPN Address Prefix Outbound Route
      Filter (L3VPN Address Prefix ORF)", that can be used to perform L3VPN
      address-prefix-based route filtering. The L3VPN Address Prefix ORF
      supports prefix-length- or range-based matching, wild-card-based address
      prefix matching, as well as the exact address prefix matching for L3VPN
      address families. The L3VPN Address Prefix ORF is applicable to reduce
      the RIB size of PE routers in the Virtual Subnet <xref
      target="I-D.ietf-l3vpn-virtual-subnet"/> context.</t>

      <section 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>
      </section>
    </section>

    <section anchor="Teminology" title="Terminology">
      <t>This memo makes use of the terms defined in <xref target="RFC5292"/>
      and <xref target="RFC4364"/>.</t>
    </section>

    <section anchor="VP" title="L3VPN Address Prefix ORF Encoding">
      <t>The ORF-Type for the L3VPN Address Prefix ORF-Type is TBD. </t>

      <t>A L3VPN Address Prefix ORF entry includes a Route Target field in
      addition to those fields which have been contained in the Address Prefix
      ORF <xref target="RFC5292"/>. That's to say, a L3VPN Address Prefix ORF
      entry consists of the following fields &lt;Sequence, Action, Match,
      Reserved, Route-Target, Minlen, Maxlen, Length, Prefix&gt;. Note that
      the Prefix field here doesn't include the Route Distinguisher (RD) part
      of a L3VPN address prefix. For example, in the case of a VPNv4 address
      prefix, only the IPv4 address prefix part of that VPNv4 address prefix
      is contained in that Prefix field.</t>

      <t> A L3VPN Address Prefix ORF entry is encoded as follows: the
      "Action", "Match" and "Reserved" fields of the entry are encoded in the
      common part <xref target="RFC5291"/>, while the remaining fields of the
      entry are encoded in the "type specific part" <xref target="RFC5291"/>,
      as shown in Figure 1. When the Action component of an ORF entry
      specifies REMOVE-ALL, the entry consists of only the common part.</t>

      <t><figure align="center"
          title="Figure 1: Type Specific Part of L3VPN Address Prefix ORF Entry Encoding">
          <artwork><![CDATA[+--------------------------------+
|   Sequence (4 octets)          |
+--------------------------------+
|   Route Target (8 octets)      |
+--------------------------------+
|   Minlen   (1 octet)           |
+--------------------------------+
|   Maxlen   (1 octet)           |
+--------------------------------+
|   Length   (1 octet)           |
+--------------------------------+
|   Prefix   (variable length)   |
+--------------------------------+
]]></artwork>
        </figure></t>
    </section>

    <section anchor="VPN" title="L3VPN Address Prefix ORF Matching ">
      <t>When performing route matching search on those L3VPN routes which are
      assocaited with the Route Target as specified in the received L3VPN
      Adress Prefix ORF entries, the Address-Prefix-ORF-specific matching
      rules as defined in <xref target="RFC5292"/> are almost preserved except
      that the RD SHOULD be ingored.</t>
    </section>

    <!---->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Mach Chen and Shunwan Zhuang for
      their comments on this document.</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>The ORF-type for the L3VPN Address Prefix ORF needs to be assigned by
      the IANA.</t>

      <!---->
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any new security considerations.</t>

      <!---->
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      <?rfc include="reference.RFC.5291"?>

      <?rfc include="reference.RFC.5292"?>
    </references>

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

      <?rfc include="reference.I-D.ietf-l3vpn-virtual-subnet"?>
    </references>
  </back>
</rfc>
