Network Working Group                                  Yakov Rekhter
Internet Draft                                      Juniper Networks
Expiration Date: October 2004                             Eric Rosen
Network Working Group                                  Cisco Systems



               Use of PE-PE GRE or IP in BGP/MPLS IP VPNs


                  draft-ietf-l3vpn-gre-ip-2547-02.txt



. Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



. Abstract


   This draft describes a variation of BGP/MPLS IP VPNs ([BGP-MPLS-VPN])
   in which the outermost MPLS label of a VPN packet (the tunnel label)
   is replaced with either IP or a GRE encapsulation. This enables the
   VPN packets to be carried over non-MPLS networks.













draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 1]

 
Internet Draft     draft-ietf-l3vpn-gre-ip-2547-02.txt        April 2004



. Specification of Requirements


   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].



. Summary for Sub-IP Area



4.1. Summary


   The base specification for BGP/MPLS IP VPNs ([BGP-MPLS-VPN])
   specifies the procedures for providing a particular style of VPN,
   using MPLS label switched paths between Provider Edge (PE) routers.
   The base specification does not discuss other types of tunnels
   between PE routers.


   This draft extends the base specification by specifying the
   procedures for providing BGP/MPLS IP VPNs using GRE or IP tunnels
   (rather than MPLS LSPs) between PE routers.



4.2. Where does it fit in the Picture of the Sub-IP Work


   This work fits squarely in the PPVPN box.



4.3. Why is it Targeted at this WG


   The WG is chartered with considering the BGP/MPLS IP VPNs. This draft
   specifies procedures to allow that style of VPN to run on networks
   which do not implement MPLS in the core routers.


   Thus the draft allows the BGP/MPLS IP VPNs to meet additional
   requirements that are not met by the base specification.



4.4. Justification


   The WG should consider this document as it extends a style of VPN
   explicitly called out in the charter so that it becomes applicable to
   a wider range of IP-based backbone environments.









draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 2]

 
Internet Draft     draft-ietf-l3vpn-gre-ip-2547-02.txt        April 2004



. Introduction


   In "conventional" BGP/MPLS IP VPNs ([BGP-MPLS-VPN]), when an ingress
   PE router receives a packet from a CE router, it looks up the
   packet's destination IP address, or in the case of Carriers' Carriers
   the packet's top MPLS label in a VRF (the VRF is chosen based on the
   packet's ingress attachment circuit ([BGP-MPLS-VPN])). As a result of
   this lookup, the (ingress) PE router obtains an MPLS label stack, a
   data link header, and an output interface. The label stack is
   prepended to the packet, the data link header is prepended to that,
   and the resulting frame is queued for the output interface.


   The bottom label in the MPLS label stack prepended to the packet is
   called the VPN route label ([BGP-MPLS-VPN]). The VPN route label will
   not be seen until the packet reaches the egress PE router. This label
   controls forwarding of the packet by the egress PE router. The upper
   label in that stack is called the tunnel label ([BGP-MPLS-VPN]). The
   purpose of the tunnel label is to cause the packet to be delivered to
   the egress PE router which understands the VPN route label.


   What we discuss here are procedures creating an MPLS packet which
   carries the VPN route label, but does not carry the tunnel label, and
   then using either GRE or IP encapsulation to carry that MPLS packet
   across the network. That is, the tunnel label is replaced with an IP
   header, and in the case of GRE encapsulation a GRE header as well.



. Motivations


   "Conventional" BGP/MPLS IP VPNs require that there be an MPLS Label
   Switched Path (LSP) between a packet's ingress PE router and its
   egress PE router.  This means that an BGP/MPLS IP VPN cannot be
   implemented if there is a part of the path between the ingress and
   egress PE routers which does not support MPLS.


   In order to enable BGP/MPLS IP VPNs to be deployed even when there
   are non-MPLS router along the path between the ingress and egress PE
   routers, it is desirable to have an alternative which allows the
   tunnel label to be replaced with either IP or (IP + GRE) header.  The
   encapsulation header would have the address of the egress PE router
   in its destination IP address field, and this would cause the packet
   to be delivered to the egress PE router.


   In this procedure, the ingress and egress PE routers themselves MUST
   support MPLS, but that is not an issue, as those routers MUST
   necessarily have BGP/MPLS IP VPN support, whereas the transit routers
   arguably should be able to be "vanilla" routers with no special MPLS
   or VPN support.




draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 3]

 
Internet Draft     draft-ietf-l3vpn-gre-ip-2547-02.txt        April 2004



. Specification


   In short, the technical approach specified here is:


      1. Continue to use MPLS to identify a VPN route, by continuing to
      add an MPLS label stack to the VPN packets. Between the ingress
      and the egress PE router the top label of the label stack will
      contain that label (the top label will be the VPN route label).


      2. An MPLS-in-GRE or MPLS-in-IP [MPLS-GRE-IP] encapsulation will
      be used to turn the above MPLS packet back into an IP packet. This
      in effect creates a GRE or an IP tunnel between the ingress PE
      router and the egress PE router.


   The net effect is that an MPLS packet gets sent through a GRE or an
   IP tunnel.



7.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE


   The following description is not meant to specify an implementation
   strategy; any implementation procedure which produces the same result
   MUST be acceptable.


   When an (ingress) PE router receives a packet from a CE router, it
   looks up the packet's destination IP address, or in the case of
   Carriers' Carriers the packet's top MPLS label in a VRF (the VRF is
   chosen based on the packet's ingress attachment circuit ([BGP-MPLS-
   VPN])). This enables the (ingress) PE router to find a VPN-IP route.
   The VPN-IP route will have an associated VPN route label and an
   associated BGP Next Hop. The label is pushed on the packet. Then an
   IP (or IP+GRE) encapsulation header is prepended to the packet,
   creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP
   source address field of the encapsulation header will be an address
   of the ingress PE router itself. The IP destination address field of
   the encapsulation header will contain the value of the associated BGP
   Next Hop; this will be an IP address of the egress PE router.


   The effect is to dynamically create an IP (or GRE) tunnel between the
   ingress and egress PE routers. No apriori configuration of the remote
   tunnel endpoints is needed. Note that these tunnels SHOULD NOT be
   IGP-visible links, and routing adjacencies SHOULD NOT be supported
   across these tunnel. Note also that the set of remote tunnel
   endpoints is not known in advance, but is learned dynamically via the
   BGP distribution of VPN-IP routes ([BGP-MPLS-VPN]). The IP address of
   the remote tunnel endpoints is carried in the Network Address of the
   Next Hop field of the MP_REACH_NLRI BGP attribute ([RFC2858]).





draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 4]

 
Internet Draft     draft-ietf-l3vpn-gre-ip-2547-02.txt        April 2004



7.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE


   We assume that every egress PE is also an ingress PE, and hence has
   the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets.
   After decapsulation, the packets SHOULD be delivered to the routing
   function for ordinary MPLS switching.



. Implications on packet spoofing


   It should be noted that if the tunnel MPLS labels are replaced with
   an unsecured IP encapsulation, like GRE or IP, it becomes more
   difficult to protect the VPNs against spoofed packets. This is
   because a Service Provider (SP) can protect against spoofed MPLS
   packets by the simple expedient of not accepting MPLS packets from
   outside its own boundaries (or more generally by keeping track of
   which labels are validly received over which interfaces, and
   discarding packets which arrive with labels that are not valid for
   their incoming interfaces).


   In contrast to protection against spoofed MPLS packets, protection
   against spoofed IP packets requires having all the boundary routers
   of the SP to perform filtering; either (a) filtering out packets from
   "outside" of the SP which are addressed to PE routers, or (b)
   filtering out packets from "outside" of the SP which have source
   addresses that belong "inside" and, in addition, filtering on each PE
   all packets which have source addresses that belong "outside" of the
   SP. The maintenance of these filter lists can be management-
   intensive, and, depending on the implementation, their use at all
   boundary routers may affect the performance seen by all traffic
   entering the SP's network. However, such filters may be required for
   reasons other than protection against spoofing of VPN packets, in
   which case the additional maintenance overhead of these filters to
   protect (among other things) against spoofing of VPN packets may be
   of no practical significance. Note that allocating IP addresses used
   for GRE or IP tunnels out of a single (or a small number of) IP block
   could simplify maintenance of the filters.


   The filtering described in the previous paragraph works only within a
   single SP network. It is not clear whether (and how) this filtering
   could be extended to support multiple SP networks. That makes the
   scheme described in this document fairly problematic in the multi-
   provider environment.









draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 5]

 
Internet Draft     draft-ietf-l3vpn-gre-ip-2547-02.txt        April 2004



. Security Considerations


   Security considerations in [MPLS-GRE-IP] apply here as well.
   Additional security issues are discussed in the section "Implications
   on packet spoofing" above.



. Acknowledgments


   Most of the text in this document is "borrowed" almost verbatim from
   draft-rosen-ppvpn-ipsec-2547-00.txt.



. Normative References


   [BGP-MPLS-VPN] "BGP/MPLS IP VPNs", Rosen E., Rekhter, Y., draft-ietf-
   l3vpn-rfc2547bis-01.txt


   [MPLS-GRE-IP] "Encapsulating MPLS in IP or Generic Routing
   Encapsulation (GRE)", Rekhter, Y., Rosen, E., draft-ietf-mpls-in-ip-
   or-gre-06.txt


   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.


   [RFC2858] "Multiprotocol Extensions for BGP-4", Rekhter, Y., Chandra,
   R., Katz, D., RFC2858, June 2000



. Authors' Addresses



Yakov Rekhter
Juniper Networks
E-mail: yakov@juniper.net


Eric C. Rosen
Cisco Systems, Inc.
 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com











draft-ietf-l3vpn-gre-ip-2547-02.txt                             [Page 6]