<?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 RFC4364 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY BGP-4 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1771.xml">
<!ENTITY DS-ARCH SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY VPN-IPv6 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY DIFF-TUNNEL SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2983.xml">
<!ENTITY RFC2858 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2858.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="info" docName="draft-mapathak-interas-option-d-00.txt"
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="Inter-AS Option D for BGP/MPLS IP VPN">
    Inter-AS Option D for BGP/MPLS IP VPN</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Manu Pathak" initials="M.P."
            surname="Pathak">
      <organization>Affirmed Networks</organization>

      <address>
        <postal>
          <street>35 Nagog Park</street>

          <!-- Reorder these if your country does things differently -->

          <city>Acton</city>

          <region>MA</region>

          <code>01720</code>

          <country>USA</country>
        </postal>

        <email>manu_pathak@affirmednetworks.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="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>

    <date month="July" year="2012" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>IDR</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 new option known as an Inter-AS option D to the
'Multi-AS  Backbones' section of [RFC4364]. This option combines VPN VRFs at 
the Autonomous System Border Router (ASBR) as described in 'Option A' 
with the distribution of labeled VPN-IP routes as described in 
'Option B'. In addition, this option allows for a data plane consisting 
of two methods of traffic forwarding between attached ASBR pairs.  
</t>
</abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
MPLS VPN providers often need to inter-connect different ASes to provide
VPN services to customers. This requires the setting up of Inter-AS
connections at ASBRs. The inter-AS connections may or may not be
between different providers. The mechanisms to set up inter-as
connections are described in [RFC4364]. Of particular interest for this
draft are the ones documented in section 10 of <xref target="RFC4364"></xref>.
</t>

<t>
For the option described in section 10, part (a) of <xref target="RFC4364"></xref>,
commonly referred to as Option A, peering ASBRs are connected by multiple 
sub-interfaces, with at least one interface for each VPN that spans the two ASes.
Each ASBR acts as a PE, and thinks that the other ASBR is a CE. The ASBRs
associate each sub-interface with a VRF and a BGP session is established per
sub-interface to signal IP (unlabeled) prefixes. As a result, traffic within
the VPN VRFs is IP. The advantage of this option is that the VPNs are isolated
from each other and since the traffic is IP, QoS mechanisms that operate on 
IP traffic can be applied to achieve customer SLAs. The drawback of this option
is that there needs to be one BGP session per sub-interface (and at least one 
sub-interface per VPN), which can be a potential scalability concern if there 
are a large number of VRFs.
</t>

<t>
For the option described in section 10, part (b) of <xref target="RFC4364"></xref>,
commonly referred to as Option B, peering ASBRs are connected by one or more
sub-interfaces that are enabled to receive MPLS traffic. An MP-BGP session 
is used to distribute the labeled VPN prefixes between the ASBRs. Therefore, the
traffic that flows between them is labeled. The advantage of this option is
that it's more scalable, as there is no need to have one sub-interface and BGP
session per VPN. The drawback of this option is that QoS mechanisms that can 
only be applied to IP traffic cannot be used as the traffic is MPLS. There is 
also no isolation between the VRFs.
</t>

<t>
The solution described in this draft aims to address the scalability
concerns of Option A by using a single BGP session to signal VPN
prefixes. In this solution, the forwarding connections between the
ASBRs are maintained on a per-VRF basis, while the control plane
information is exchanged using a single MP-BGP session.
</t>

<t>
If the solution is used between any attached ASBR pairs belonging 
to separate Autonomous Systems (AS), then VRF based route filtering 
policies via RTs is achieved directly between ASBR pairs, independent 
of PE based RT filtering within an AS.
</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="Scope">
<t>
The Inter-AS VPN option described in this draft is applicable to both, 
the IPv4 VPN services described in [RFC4364] and the IPv6 VPN services 
defined in [VPN-IPv6]. It is NOT applicable to MVPN IPv4 and MVPN
IPv6 services defined in [RFC6513].

Support of existing 'Multi-AS' options, along with the new techniques
are beyond the scope of this document. 
</t>
</section>

<section title="Inter-AS Option D Reference Model">
<t>
Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario 
between Customer Edge routers. CE1 and CE3, interconnected by 
Service Providers SP1 and SP2, belong to the same VPN, say Red.
CE2 and CE4 belong to a different VPN, say Green. This example shows 
3 interfaces ('red', 'white' and 'green') between ASBR1 (belonging to SP1)
and ASBR2 (belonging to SP2).
</t>

<t>
Interface 'red' is a VRF attachment circuit associated to VRF1 (on
ASBR1 and ASBR2) for VPN Red and is used to trasport labeled or native
IP VPN traffic between VRF pairs.

Similarly, interface 'green' is a VRF attachment circuit associated to
VRF2 (on ASBR1 and ASBR2) for VPN Green and is used to transport labeled
or native IP VPN traffic between VRF pairs.

Interface 'white' is not associated with any VRF instances i.e. this 
interface is 'global' in nature (in the context of the connected ASes)
and carries as a minimum all ASBR exported VPN-IP routing updates. 
</t>

<t>

We shall use the term "private interface forwarding" to describe the
model where packets for the "Red" VPN are forwarded on the "red"
interface, while packets belonging to "Green" VPN are forwarded on
the "green" interface. There are no BGP sessions running on the "red"
and "green" interfaces; rather the 'white' interface carries all ASBR
VPN-IP routing updates exported from VRF pairs.

We shall use the term "shared interface forwarding" to describe the
model where the "white" interface will be used to forward all the 
traffic between the ASBRs. For shared interface forwarding outside of
a VRF context, interfaces 'red' and 'green' are not required. In
addition to carrying all ASBR VPN-IP routing updates, interface 'white'
transports labeled IP VPN traffic or native IP traffic. IP VPN packets
entering or leaving the ASBR via this interface may be forwarded using
normal MPLS mechanisms (e.g. through use of the LFIB) or through a 
lookup within a VRF that has been identified via MPLS label values. 
</t>

<t>
</t>

<t>
      <figure align="center">
        <artwork align="left"><![CDATA[


                  CE1----\    /--------RR1--------\
                          \  /                     \
                           PE1---SP1 MPLS Cloud---ASBR1
                           /                     /  |  \
                  CE2-----/                 red /   |   \ green
                                               /  white  \
                                               \    |    /
                  CE3-----\                     \   |   /
                           \                     \  |  /
                            PE2--SP2 MPLS Cloud---ASBR2
                           / \                     /
                   CE4----/   \--------RR2--------/

                   Figure 1
            ]]></artwork>
      </figure>
</t>

<t>
In the diagram above:
</t>

<t>
1. CE1 and CE3 belong to VPN Red.
</t>

<t>
2. CE2 and CE4 belong to VPN Green.
</t>

<t>
3. PE1 uses RDs RD-red1 and RD-green1 for VPN Red (VRF Red) and VPN Green 
   (VRF Green) respectively.
</t>

<t>
4. PE2 uses RDs RD-red2 and RD-green2 for VPN Red (VRF Red) and VPN Green
  (VRF Green) respectively.
</t>

<t>
5. ASBR1 has VRFs Red and Green provisioned with RD-red3 and RD-green3
   respectively.
</t>

<t>
6. ASBR2 has VRFs Red and Green provisioned with RD-red4 and RD-green4
   respectively.
</t>

<t>
7. There are 3 interfaces between ASBR1 and ASBR2.
</t>

<t>
8. On each ASBR, one interface is associated with VRF Red and one with VRF Green.
   These are the interfaces marked "red" and "green" respectively.
</t>

<t>
9. There is a third interface over which there is an MP-BGP session between the
   ASBRs. This is the interface marked "white".
</t>

<t>
10. VPN route importing is achieved by configuring the appropriate RTs.
</t>

<t>
11. The PE and ASBR routers in each AS peer with a route-reflector in that AS.
</t>

<t>
The following sections describe in detail the different modes of operation for
Option D.
</t>

</section>

<section title="Private Interface Operation without Carrier's Carrier (CSC)">
<t>
This section describes how route distribution and packet forwarding
takes place when using the private interface forwarding option without
the use of CSC, ie. the traffic sent between the private interfaces is 
unencapsulated.
</t>

<t>
Route Distribution:
</t>

<t>
[The following description is for VPN Red, but Route Distribution for VPN
Green is exactly analogous to this]
</t>

<t>
1. CE1 advertises a prefix N to PE1.
</t>

<t>
2. PE1 advertises a VPN prefix RD-red1:N to RR1, which in turn advertises it to
   ASBR1 via iBGP.
</t>

<t>
3. ASBR1 imports the prefix into VPN Red and creates a prefix RD-red3:N.
</t>

<t>
4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets itself as
   the next-hop for this prefix and also allocates a local label that is signaled
   with the prefix.
</t>

<t>
5. By default, ASBR1 does not advertise the source prefix RD-red1:N to ASBR2. This
   advertisement is suppressed as the prefix is being imported into an Option
   D VRF.
</t>

<t>
6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red as RD-red4:N.
</t>

<t>
7. While installing the prefix into the VRF Red RIB table, ASBR2 sets the
   nexthop of RD-red4:N to ASBR1s interface address in VRF Red. The routing
   context for this entry is also set to that of VRF Red.
</t>

<t>
8. While installing the MPLS forwarding entry for RD-red4:N, by default, the
   label that was advertised by ASBR1 for the prefix is not installed in 
   the Forwarding Information Base. This enables the traffic between the ASBRs
   to be IP.
</t>

<t>
9. ASBR2 advertises the imported prefix RD-Red4:N to RR2, which in turn advertises
   it to PE2. It sets itself as the next-hop for this prefix and also allocates a
   local label that is signaled as part of the VPN-IP NLRI.
</t>

<t>
10. By default, ASBR2 does not advertise the source prefix RD5:N to PE2. This
   advertisement is suppressed.
</t>

<t>
11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N.
</t>

<t>
Packet Forwarding
</t>

<t>
The packet forwarding would work just as it would in an Option A scenario:
</t>

<t>
1. CE3 sends a packet destined for N to PE2.
</t>

<t>
2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 and
   the IGP label (if any) needed to tunnel the packet to ASBR2.
</t>

<t>
3. The packet arrives on ASBR2 with the VPN Label, ASBR2 pops the VPN Label
   and sends the packet as IP to ASBR1 on the "red" interface.
</t>

<t>
4. The IP packet arrives at ASBR1 on the "red" interface. ASBR1 then 
   encapsulates the packet with the VPN Label allocated by PE1 and the IGP
   label needed to tunnel the packet to PE1.
</t>

<t>
5. The packet arrives on PE1 with the VPN label; PE1 disposes the VPN label
   and forwards the IP packet to CE1.
</t>

</section>

<section title="Private Interface Forwarding with CSC">
<t>
Let's assume that VPN Red is used to provide VPN service to its customer 
carrier who in turn provides a VPN service to a customer. This implies that VPN
RED is used to provide an LSP between the PE (PE3 and PE4) loopbacks of the
baby carrier in the following topology:
</t>

<t>
      <figure align="center">
        <artwork align="left"><![CDATA[

                              /--------RR1--------\
                             /                     \
   PE3---(CSC-)CE1---(CSC-)PE1---SP1 MPLS Cloud---ASBR1
                                                  |   |
                                                  |   |
                                             white|   |red
                                                  |   |
                                                  |   |
   PE4---(CSC-)CE2---(CSC-)PE2---SP2 MPLS Cloud---ASBR2
                            \                       /
                             \--------RR2----------/

   Figure 2
            ]]></artwork>
      </figure>
</t>

<t>
Thus, let's assume that in the diagram above:
</t>

<t>
1. CSC-PE1 uses RD RD-red1 for VPN Red (VRF Red).
</t>

<t>
2. CSC-PE2 uses RD RD-red2 for VPN Red (VRF Red).
</t>

<t>
3. ASBR1 has VRF Red provisioned with RD-red3.
</t>

<t>
4. ASBR2 has VRF Red provisioned with RD-red4.
</t>

<t>
5. There are 2 interfaces between ASBR1 and ASBR2.
</t>

<t>
6. On each ASBR, one interface is associated with VRF Red. This is the interface
   marked "red" in the Figure 2.
</t>

<t>
7. There is a second interface over which there is an MP-BGP session between the
   ASBRs. This interface is in the global context and is marked "white" in the
   figure.
</t>

<t>
Route Distribution:
</t>

<t>
1. CSC-CE1 advertises PE3s loopback N to PE1.
</t>

<t>
2. CSC-PE1 advertises a VPN prefix RD-red1:N to RR1, which advertises it to ASBR1
   via MP-iBGP.
</t>

<t>
3. ASBR1 imports the prefix into VPN Red and creates a prefix RD-red3:N.
</t>

<t>
4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets itself as
   the next-hop for this prefix and also allocates a local label that is
   signaled as part of the VPN-IP NLRI.
</t>

<t>
5. By default, ASBR1 does not advertise the source prefix RD-red1:N to ASBR2.
   This advertisement is suppressed as the prefix is being imported into an
   Option D VRF.
</t>

<t>
6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red as
   RD-red4:N.
</t>

<t>
7. While installing the prefix into the VRF Red RIB table, ASBR2 sets the
   nexthop of RD-red4:N to ASBR1s interface address in VRF Red. The nexthop
   routing context is also set to that of VRF Red.
</t>

<t>
8. While installing the MPLS forwarding entry for RD-red4:N, the outgoing label
   is installed in forwarding. This enables the traffic between the ASBRs to be
   MPLS.
</t>

<t>
9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which advertises it
   to CSC-PE2. It sets itself as the next-hop for this prefix and also
   allocates a local label that is signaled as part of the VPN-IP NLRI.
</t>

<t>
10. By default, ASBR2 does not advertise the source prefix RD-red4:N to PE2.
    This advertisement is suppressed.
</t>

<t>
11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N.
</t>

<t>
Packet Forwarding:
</t>

<t>
1. PE4 sends a MPLS packet destined for N to CSC-CE2.
</t>

<t>
2. CSC-CE2 swaps the MPLS label and sends a packet destined for N to CSC-PE2.
</t>

<t>
3. CSC-PE2 encapsulates the packet with the VPN label allocated by ASBR2 and
   the IGP label needed (if any) to tunnel the packet to ASBR2.
</t>

<t>
4. The packet arrives on ASBR2 with the VPN Label, ASBR2 swaps the received
   VPN label with the outgoing label received from ASBR1 and sends the MPLS
   packet on to the VRF Red interface.
</t>

<t>
5. The MPLS packet arrives at ASBR1 on the VRF red interface, ASBR1 then
   swaps the received MPLS label with a label stack consisting of the VPN Label
   allocated by PE1 and the IGP label needed to tunnel the packet to CSC-PE1.
</t>

<t>
6. The packet arrives on CSC-PE1 with the VPN label; PE1 disposes the VPN
   label and forwards the MPLS packet to CSC-CE1.
</t>

<t>
7. CSC-CE1 in turn swaps the label and forwards the labeled packet to PE3.
</t>
</section>

<section title="Shared Interface Forwarding">

<t>
This section describes how route distribution and packet forwarding
takes place when using the shared interface forwarding option. The
topology is the same as in Figure 1.
</t>

<t>
Route Distribution (VPN Red):
</t>

<t>
1. CE1 advertises a prefix N to PE1.
</t>

<t>
2. PE1 advertises a VPN prefix RD-red1:N to RR1, which advertises it to ASBR1
   via iBGP.
</t>

<t>
3. ASBR1 imports the prefix into VPN Red and creates a prefix RD-red3:N
</t>

<t>
4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets itself as the
   next-hop for this prefix and also allocates a local label that is signaled
   with the prefix.
</t>

<t>
5. By default, ASBR1 does not advertise the source prefix RD-red1:N to ASBR2.
   This advertisement is suppressed as the prefix is being imported into an
   Option D VRF.
</t>

<t>
6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red as RD-red4:N
</t>

<t>
7. While installing the prefix into the VRF Red RIB table, ASBR2 retains the
   nexthop of RD-red4:N as received in the BGP update from ASBR1. This is the
   address of ASBR1's s shared interface address in the global table. The
   nexthop routing context is also left unchanged and corresponds to that of
   the global table.
</t>

<t>
8. While installing the MPLS forwarding entry for RD-red4:N, the outgoing label
   is installed in forwarding. This enables the traffic between the ASBRs to be
   MPLS.
</t>

<t>
9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which advertises it to
   PE2. It sets itself as the next-hop for this prefix and also allocates a local
   label that is signaled as part of the VPN-IP NLRI.
</t>

<t>
10. By default, ASBR2 does not advertise the source prefix RD-red4:N to PE2. This
   advertisement is suppressed.
</t>

<t>
11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N.
</t>

<t>
Packet Forwarding:
</t>

<t>
The packet forwarding would work just as it would in an Option B scenario:
</t>

<t>
1. CE3 sends a packet destined for N to PE2.
</t>

<t>
2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 and
   the IGP label needed to tunnel the packet to ASBR2.
</t>

<t>
3. The packet arrives on ASBR2 with the VPN Label. ASBR2 swaps the received
   VPN label with the outgoing label received from ASBR1 and sends the MPLS
   packet on to the global shared link interface.
</t>

<t>
4. The MPLS packet arrives at ASBR1 on the global shared link interface.
   ASBR1 then swaps the received MPLS label with a label stack consisting of
   the VPN Label allocated by PE1 and the IGP label needed to tunnel the packet
   to PE1.
</t>

<t>
5. The packet arrives on PE1 with the VPN label; PE1 disposes the VPN label
   and forwards the IP packet to CE1.
</t>

</section>

<section title="Route Advertisement to External BGP Peers">
<t>
ASBR1 (refer Figure 1) does route advertisement and VPN route processing using the
standard BGP-VPN rules. It processes the VRF Red RT extended community 
attributes and learns the label bindings associated with routes for 
VPN Red. VPN-IP routes are imported into VRF Red's Routing Information 
Base (RIB) where their RT and RD attributes, assigned by PE1 are 
removed.
</t>

<t>
ASBR1 VPN-IP routes are not advertised to RR1 as the original routes
applicable to VPN Red sourced by PE1 were received from an internal
BGP peer. Any installed routes that are not imported into VRF1 RIB MAY
be advertised to external BGP peers using the existing [RFC4364] Multi-AS
"Option B" techniques. Dependant on which packet forwarding method is 
used, routes are then exported from VRFs and advertised from ASBR1 to
ASBR2 as described in the following sections.
</t>

<section title="Route Advertisement - Private interface forwarding"> 
<t>
VPN-IP prefixes are advertised from ASBR1 to ASBR2 via a BGP 
session that is in the global routing table context. This implies 
that the advertised next-hop address is also reachable via the global 
routing table context. In order to force traffic to be forwarded via 
an interface 'red' that is in a VRF routing table context, VRF 
forwarding entries need to be installed using a next-hop address that 
is in VRF Red's (which resides on ASBR2) routing context. The address 
of the next-hop could be the same as the global table address of the 
remote ASBR (in this case ASBR1), although this would require that 
the same IP address be used across all VRF attachment circuits 
linking ASBR pairs.  
</t>

<t>
Alternatively, if a Service Provider needs to number the VRF interfaces 
differently from the global table VPN session, a configuration method SHOULD
be available so as to map the corresponding global table VPNv4 neighbor address
to an IP address reachable in the given VRF.  
</t>

<t>
ASBR1 exports routes associated to VPN Red from VRF Red's RIB to BGP
where RD and RT attributes, plus label bindings are attached to these 
routes. These labeled VPN-IP routes are advertised across interface 
'red' to ASBR2 via BGP, with a label value set to implicit-null and the 
'S' bit set. The routes next-hop addresses is set either to ASBR1 
(usually interface 'red') or an address reachable via interface 'red'. 
ASBR2 imports the VRF Red's exported routes into VRF Red's RIB where the 
routes RT and RD attributes are removed. The next-hop of the imported
routes is either set via a policy or left unchanged to an address in 
VRF Red's routing context. ASBR2 exports routes from VRF Red's RIB 
to BGP and attaches RT and RD attributes, as configured at VRF Red 
plus label bindings. Labeled VPN-IP routes are now advertised to PE2 
via RR2 and so on. ASBR2 sets itself as the nexthop for these routes
abd allocates a local label. As an optimization to conserve label space,
ASBR2 MAY allocate a per-VRF aggregate label as the local label while 
advertising the routes to iBGP peers.
</t>
</section>


<section title="Route Advertisement - Shared interface forwarding">
<t>
ASBR1 exports routes associated to VPN Red from VRF Red's RIB to BGP
where RD and RT attributes, plus label bindings are attached to these 
routes. These labeled VPN-IP routes are advertised across interface 
'white' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports
 the VRF Red exported routes into (its local) VRF Red RIB where the routes
RT and RD attributes are removed. The imported routes next-hop is set
to ASBR1, available via interface 'white'. ASBR2 exports routes from VRF
Red's RIB to BGP and attaches RT and RD attributes, as configured at
VRF Red plus label bindings. Labeled VPN-IP routes are now 
advertised to PE2 via RR2 and so on.
</t>
</section>


<section title="Route Advertisement to Internal BGP Peers"> 
<t>
All the received VPN-IP routes from an adjancent ASBR are imported
into local VRFs on the receiving ASBR. The receiving ASBR needs
to advertise these routes to its local IBGP sessions. The next-hop
for these routes SHOULD be set to itself when the local
ASBR advertises these routes to its IBGP sessions.
</t>
</section>
</section>

<section title="Option D Operation Requirements">
<section title="Inter-AS IP VPN Route Distribution">
<t>
Routes received from internal or external peers that are imported 
into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. 
Routes that are not imported into VRFs but are installed in the 
ASBR's global routing table MAY be readvertised using existing Option 
'B' techniques as described in the Multi-AS section of [RFC4364]. The 
ASBR MUST be equipped with RT based filtering mechanisms that 
explicitly permit all or a subset of such RT values to be 
readvertised to its neighbors.      
</t>

<t>
VPN-IP routes that are converted by the ASBR MUST NOT be readvertised 
to the source peer of the route. It SHOULD be possible to remove/manipulate 
individual RT values when advertising routes on a per neighbor basis. This 
is useful where the SP wants to separate RT values advertised to 
EBGP peers from RT values advertised to IBGP peers.
</t>
</section>

<section title="Private Interface Forwarding Route Distribution">
<t>
For private interface forwarding, labeled VPN-IP routes advertised 
from ASBR to ASBR MUST have their next-hop set to an address within a 
VRF RIB. This address will usually be the VRF attachment circuit 
interface.
</t>

<t>
If the Service Provider needs to number the VRF interfaces 
differently from the global table VPNv4 neighbor, a configuration 
method SHOULD be available so as to map the corresponding global 
table VPNv4 neighbor address to an IP address reachable in the given 
VRF. This route mapping policy SHOULD be configurable on both 
outbound and inbound peers.
</t>
</section>

<section title="Shared interface forwarding Route Distribution">
<t>
For shared interface forwarding outside of a VRF context, the next-
hop must be a 'global' (non VRF RIB) address on an ASBR. This address 
will usually be the interface linking ASBR pairs.
</t>
</section>
</section>

<section title="Inter-AS Quality of Service for Option D">
<t>
It SHOULD be possible for the ASBR as a DS boundary node [DS-ARCH] 
operating traffic classification and conditioning functions to match 
on ingress and egress a combination of application (TCP, UDP port, 
RTP session, data pattern etc), IP Source Address, IP Destination 
Address or DS field per packet, per VRF or per VRF attachment circuit 
(in the case of private interface forwarding). 
</t>

<t>
Once matched, the packets Layer-2 header (if applicable), IP DSCP and 
MPLS EXP bits or combinations of the above should be capable of being 
re-marked, and optionally shaped per traffic stream, depending on the 
DS domain's Traffic Conditioning Agreement (TCA). This will assist 
where different DS domains have different TCA rules.
</t>

<t>
For Private interface forwarding, the ASBR should be capable of 
forwarding explicit null labeled MPLS packets across VRF attachment 
circuits. This SHOULD assist with a pipe mode [DIFF-TUNNEL] operation 
of traffic conditioning behavior at the ASBR. MPLS based forwarding 
between attached ASBRs inherently should have these mechanisms built 
in. 
</t>
</section>

<section title="Security Considerations">
<t>
This document doesnt not alter the underlying security properties of
BGP based VPNs. In particular, the the private interface forwarding
using a new Multi-AS option defined in this document has same security 
implications as Multi-AS option 'a'of [RFC4364]. The global interface
forwarding using a new Multi-AS option defined in this document is
outside the scope of this document.
</t>

<t>
This document doesnt not alter the underlying security properties of
BGP based VPNs for the shared interface forwaring using the new Multi-AS
option. The security implications for this mechanism are same as
Multi-AS option 'b' of [RFC4364]. 
</t>
</section>

<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors wish to acknowledge the contributions of the authors of the
original Option D draft: Marko Kulmala, Ville Hallivuori, Jyrki Soini,
Jim Guichard, Robert Hanzl and Martin Halstead. The authors would like
to thank Eric Rosen for his comments.
</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.4364.xml"?-->
      &RFC2119;

      &RFC4364;

<!--      &RFC2474; -->

    </references>

    <references title="Informative References">
      &RFC2858;

<!--      &RFC4659; -->

<!--      &RFC2983; -->
    </references>
    <!-- Change Log

v00 2011-09-01  KP    Initial version
    -->
  </back>

</rfc>
