One document matched: draft-l3vpn-legacy-rtc-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" [
<!-- 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 RFC1997 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!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 RFC4271 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4684 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4684.xml">
<!ENTITY RFC4364 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4360 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY I-D.draft-chen-bgp-ext-community-orf-00 SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-chen-bgp-ext-community-orf-00.xml">
<!ENTITY I-D.keyur-bgp-af-specific-rt-constrain SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-keyur-bgp-af-specific-rt-constrain-00.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-l3vpn-legacy-rtc-00"
ipr="pre5378Trust200902">
  <!-- 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="legacy PE RT Filtering">
    Automatic Route Target Filtering for legacy PEs </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

     <author fullname="Pradosh Mohapatra" initials="P.M."
            surname="Mohapatra">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <email>pmohapat@cisco.com</email>

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

    <author fullname="Arjun Sreekantiah" initials="A.S."
            surname="Sreekantiah">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <email>asreekan@cisco.com</email>

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

    
    <author fullname="Keyur Patel" initials="K.P."
            surname="Patel">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <email>keyupate@cisco.com</email>

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

    <author fullname="Alton Lo" initials="A.L."
            surname="Lo">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <email>altonlo@cisco.com</email>

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

    
    <date day="02" month="March" year="2011" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>L3VPN</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 describes a simple procedure that allows "legacy"
   BGP speakers to exchange route target membership information in 
   BGP without using mechanisms specified in RFC 4684.  
   The intention of the proposed technique is to help in partial deployment
   scenarios and is not meant to replace RFC 4684.
</t>
</abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
   <xref target="RFC4684"></xref>, "Constrained Route Distribution for Border Gateway 
   Protocol/ MultiProtocol Label 
   Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)" provides a 
   powerful and general means for BGP speakers to exchange and propagate Route Target reachability 
   information and constrain VPN route distribution to achieve high scale.  However, it requires 
   that all the BGP speakers in the network are upgraded to support this functionality. For 
   example, in a network with route reflectors (RR), if one PE client in the cluster doesn't 
   support constrained distribution, the cluster degenerates into storing and processing all the 
   VPN routes. The 
   route reflectors need to request and store all the network routes since they do not receive 
   route target membership information from the legacy PEs. The RR will also generate all those
   routes to the legacy PEs and the legacy PEs will end up filtering the routes and store the
   subset of VPN routes that are of interest.
</t>
<t>
   This document specifies a mechanism for such legacy PE devices using existing configuration and 
   toolset to provide similar benefits as <xref target="RFC4684"></xref>. At the same time, it is backward-compatible
   with the procedures defined in <xref target="RFC4684"></xref>. It also allows graceful upgrade of the legacy
   router to be <xref target="RFC4684"></xref> capable.
</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> <!-- for Introductions section -->

<section title="Basic Idea"
        anchor="bidea">
<t>
   The basic idea is to make use of VPN unicast route exchange from the legacy PEs to a new
   BGP speaker (e.g. an RR) to signal RT membership. The legacy PEs announce a set of "special" 
   routes with mapped RTs to the RR along with a standard community (defined in this document). The 
   presence of the community triggers the RR to extract the RTs and build RT membership information.
</t>
</section>

<section title="Detailed Operation"
        anchor="operation">
<section title="Legacy PE Behavior">
<t>
  The following simple steps are performed on the legacy PE device:
<list style="symbols">
<t>
Collect the "import route targets" of all the configured customer VRFs. Let's call this
set 'IRTS'.
</t>
<t>
Create a special "route-filter VRF" with a route distinguisher(RD) that's configured with 
the same value across the network for all legacy PE devices. Note: the equivalence of the
RD value is for optimization - the operator may choose to use different values.
</t>
<t>
Originate one or more routes in this VRF and attach a subset of 'IRTS'
  as "translated  route-target extended communities" with each route so as to evenly 
  distribute the RTs (and to make sure they can fit into one BGP UPDATE message). 
  Collectively,  the union of the "translated route-target extended communities" of all these routes 
is equal to 
  the set 'IRTS'. The translated RTs are attached as export route-targets for the routes originated 
  in the route-filter VRF.
</t>
<t>
The translation of the IRTs is necessary in order to refrain from importing "route-filter" VRF routes into 
  VPN VRFs that would import the same route-targets. The translation of the IRTS is done as follows. 
  For a given IRT, the equivalent translated RT (TRT) is constructed by means of swapping the value of the 
  high-order octet of the Type field for the IRT (as defined in <xref target="RFC4360"></xref>).
      <figure align="center">
      <preamble></preamble>
        <artwork align="left"><![CDATA[
    0                   1              0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x00     |     0x02      |   |      0x01     |     0x02      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |2B AS                          |   |2B AS => IP(high)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Local Admin(high)              |   |Local Admin(high) => IP(low)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Local Admin(low)               |   |Local Admin(low) => Local Admin|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1              0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x01     |     0x02      |   |      0x02     |     0x02      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |IP(high)                       |   |IP(high) => 4B AS(high)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |IP(low)                        |   |IP(low) => 4B AS(low)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Local Admin                    |   |Local Admin => Local Admin     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1              0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x02     |     0x02      |   |      0x00     |     0x02      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |4B AS(high)                    |   |4B AS(high) => 2B AS           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |4B AS(low)                     |   |4B AS(low) => Local Admin(high)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Local Admin                    |   |Local Admin => Local Admin(low)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>
      </figure>
  As an example, if IRT R= 65500:12244(hex: 0x0002ffdc00002fd4),
  equivalent route-filter TRT: 255.220.0.0:12244(hex: 0x0102ffdc00002fd4). One shortcoming of the translation
  mechanism is a possible collision between IRTs and TRTs if the network has been configured with RTs of
  multiple higher order octet types (2-byte AS, IP address, and 4-byte AS). It is expected that such a
  configuration is rare in practice.
</t>
<t>
  As an alternative to the translation of the IRTS, the subset of the 'IRTS' can be attached as-is 
  (without swapping the type field as described earlier) as "export route-target extended communities"
  with each route so as to evenly distribute the RTs (and to make sure they can fit into one BGP 
  UPDATE message).
  In this case, the IRT subsets can be attached in outbound policy to avoid the route-filter VRFs from being 
  imported into VPN VRFs. Also in this case, the route-filter VRF routes must be tagged with a different 
  special community (from that associated with the translated RTs) as described in <xref target="community">
  </xref> so that the receiving BGP speaker can distinguish the two cases.
</t>
<t>
  The routes are marked with NO_ADVERTISE and NO_EXPORT well-known communities as well as the appropriate 
  new community that's defined in this document <xref target="community"></xref>. Note that there is no
  specific provision made to disallow configuration of subsequent route policies that can potentially
  alter the set of communities attached to "route-filter" VRF routes. The protocol behavior in
  such a case is undefined and the use of those policy statements is discouraged.
</t>
</list>
</t>
<t>
</t>
</section>
<section title="RR behavior">
<t>
  Upon receiving the "route-filter" routes, the BGP speaker
  does its usual processing to store them in its local RIB. It recognizes them as route-filter
  routes based on the association of the new standard community as defined in this
  document. If required (as indicated by the community value),
  it translates the attached route-target extended communities (TRT) to equivalent
  import route-targets (IRT). Finally it creates the route-target filter list for each legacy
  client by collecting the entire set of route targets.

  From this point onwards, the behavior is similar to that defined in <xref target="RFC4684"></xref>. The
  RR does not propagate the routes further because of their association with NO_ADVERTISE 
  community.

  Also the VPN EoR that is sent by the legacy PE should also be used as an indication that the 
  legacy PE is done 
  sending the route-filter information as per the procedures defined in <xref target="RFC4684"></xref> 
  for implementing a EoR mechanism
  to signal the completion of initial RT membership exchange.
</t>
<section title="Generating Route Target Membership NLRIs for the legacy PE clients">
<t>
  The RR MAY also translate the received extended communities from legacy clients into route
  target membership NLRIs as if it had received those NLRIs from the client itself. This is
  useful for further propagation of the NLRIs to rest of the network to create RT membership
  flooding graph. When the route_filter routes are received with same RD (from all legacy PE
  speakers), processing of the paths to generate equivalent NLRIs becomes fairly easy.
</t>
</section>
</section>
</section>

<section anchor="community" title="ROUTE_FILTER community">
<t>
  This memo defines four BGP communities that are attached to BGP UPDATE messages at the
  legacy PE devices and processed by the route reflectors as defined above. They are as
  follows:
</t>
        <texttable>

          <ttcol align="center">Community</ttcol>

          <ttcol align="left">Meaning</ttcol>

          <c>ROUTE_FILTER_v4</c>

          <c>RTs are attached as-is for VPNv4 route filtering</c>

          <c>...</c>

          <c>...</c>

          <c>ROUTE_FILTER_v6</c>

          <c>RTs are attached as-is for VPNv6 route filtering</c>

          <c>...</c>

          <c>...</c>

          <c>ROUTE_FILTER_TRANSLATED_v4</c>

          <c>Translated RTs are attached for VPNv4 route filtering</c>

          <c>...</c>

          <c>...</c>

          <c>ROUTE_FILTER_TRANSLATED_v6</c>

          <c>Translated RTs are attached for VPNv6 route filtering</c>

	  
        </texttable>

<t>
In the absence of (or lack of support of) AF specific communities (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6), the ROUTE_FILTER_v4 or ROUTE_FILTER_TRANSLATED_v4  MAY be treated by an implementation as a default VPN route-filter community 
to build a combination VPN filter for all VPN AFs (VPNv4, VPNv6) present on the RR. This is in 
accordance with the procedures in <xref target="RFC4684"></xref> to build combination route-filters 
for VPN AFs and AF specific route-filters defined in <xref target="I-D.keyur-bgp-af-specific-rt-constrain"> </xref>. 
If this is the case, then subsequent receipt of any "route-filter" routes with AF specific 
communities (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6) will override the default filters sent 
with ROUTE_FILTER_v4 or ROUTE_FILTER_TRANSLATED_v4 for the VPNv6 AFI when
support for the AF specific communities exists.
</t>
</section>

<section title="Deployment Considerations">
<t>
When both the legacy PE and the RR support extended community based Outbound Route Filtering as in [I-D.draft-chen-bgp-ext-community-orf-00] this may be used as a alternate solution for the legacy PE to signal RT membership information, in order to realize the same benefits as <xref target="RFC4684"></xref>. Also extended community ORF can be used amongst the RRs in lieu of <xref target="RFC4684"></xref> to realize similar benefits.
</t>
</section>

<section title="Contributors">
<t>
Significant contributions were made by Luis M Tomotaki and James Uttaro which the authors would like 
to acknowledge.
</t>
</section>

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

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
<t>
IANA shall assign new code points from BGP first-come first-serve communities
for the four communities as listed in <xref target="community"></xref>.
</t>
    </section>

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

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

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

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629;
        here (as shown)
    2. simply use a PI
        "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds:
          include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included
    files in the same directory as the including file. You can also define
    the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be
    either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC4271;

      &RFC4360;

      &RFC4364;

      &RFC4684;
   
      &I-D.keyur-bgp-af-specific-rt-constrain;

      &I-D.draft-chen-bgp-ext-community-orf-00;

    </references>
    <!-- Change Log
v00 2010-09-17  PM    Initial version
    -->
  </back>
</rfc>