Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: Informational                                P. Francis
Expires: March 27, 2010                                          MPI-SWS
                                                      September 23, 2009


   Proposal to use an inner MPLS label to identify the remote ASBR VA
               draft-ietf-grow-va-mpls-innerlabel-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on March 27, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The draft "MPLS Tunnels for Virtual Aggregation"
   [I-D.ietf-grow-va-mpls] specifies how MPLS is used as the tunneling



Xu & Francis             Expires March 27, 2010                 [Page 1]

 
Internet-Draft                VA MPLS Label               September 2009


   protocol for Virtual Aggregation (VA).  The -00 version of that draft
   specifies only one level of labels, with the result that one Label
   Switched Path (LSP) for every remote ASBR must be established.  For
   large ISPs, this can amount to a large number of LSPs.  This draft
   proposes adding the option of using an inner label to identify the
   remote ASBR.  Either an outer label or an IP tunnel is used to reach
   the local ASBR.  When MPLS is used as the tunneling protocol, this
   reduces the number of LSPs to the number of local border routers
   (ASBR).


Table of Contents

   1.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . . . 5
     1.2.  Changes from Previous Versions  . . . . . . . . . . . . . . 5
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   4.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6































Xu & Francis             Expires March 27, 2010                 [Page 2]

 
Internet-Draft                VA MPLS Label               September 2009


.  Proposal

   The draft "MPLS Tunnels for Virtual Aggregation"
   [I-D.ietf-grow-va-mpls] specified how MPLS is used as the tunneling
   protocol for Virtual Aggregation (VA).  The -00 version of that draft
   specifies only one level of labels, with the result that one LSP for
   every remote ASBR must be established.  For large ISPs, this can
   amount to a large number of LSPs (roughly 20,000 for one large ISP we
   studied).  This draft proposes the optional use of an inner label to
   reduce the number of LSPs to the number of local ASBRs.  Besides
   improving the efficiency of VA, this also makes it feasible to use
   MPLS TE (traffic engineered) LSPs.

   VA requires that tunneled packets are "targeted" to remote ASBRs.
   However, the tunnel header must be stripped before the packet is
   transmitted to the remote ASBR.  This means that the tunnel header
   must identify the remote ASBR to the local ASBR, so that the local
   ASBR may strip the header and forward the packet to the remote ASBR.
   In the -00 draft of [I-D.ietf-grow-va-mpls], there is one LSP per
   remote ASBR.  In other words, there is a distinct label per remote
   ASBR.

   This draft proposes adding the option of using an inner label to
   identify the remote ASBR.  Either an outer label or an IP tunnel
   identifies the local ASBR.  When the local ASBR receives the packet,
   it strips off the outer label/header, uses the value of the inner
   label to identify the remote ASBR, and then strips the inner label
   before forwarding the packet to the remote ASBR.  Note that, in the
   case of stacked labels, the outer label may have been stripped by the
   previous hop using penultimate hop popping (PHP).

   This style of tunneling is essentially identical to that used for
   MPLS VPNs [RFC4364], though simpler because there is no need for
   virtual forwarding tables.

   There are three forms of tunneling that can be used, stacked labels
   ([RFC3032]), and MPLS-in-IP or MPLS-in-GRE ([RFC4023]), as follows:

     Stacked labels (RFC3032):
       Payload | IP | Inner label | Outer label | link | ==>

     MPLS-in-IP (RFC4023):
       Payload | IP | Inner label | Outer IP header | link | ==>

     MPLS-in-GRE (RFC4023):
       Payload | IP | Inner label | GRE | Outer IP header | link | ==>

   When a local ASBR advertises a route into iBGP, it sets the Next Hop



Xu & Francis             Expires March 27, 2010                 [Page 3]

 
Internet-Draft                VA MPLS Label               September 2009


   to itself, and assigns a label to the route.  This label is used as
   the inner label, and identifies the remote ASBR from which the route
   was received [RFC3107].

   The presence of the inner label in the iBGP update acts as the signal
   to the receiving router that an inner label should be used in packets
   tunneled to the Next Hop address.  Other information is used to
   determine whether the tunnel itself is MPLS, IP, or GRE.
   Specifically, [I-D.ietf-grow-va-gre]. specifies how to convey the use
   of IP or GRE tunneling in BGP for VA (i.e. though the attributes from
   [RFC5512]).  If these attributes indicate IP or GRE tunneling, then
   the corresponding IP or GRE tunnel should be used.  If no 5512
   attribute is present, but there is a LSP to the Next Hop address,
   then the LSP should be used.  If no 5512 attribute is present, and
   there is no LSP to the Next Hop address, then the packet should be IP
   tunneled to the Next Hop address.

   The following table summarizes the tunneling behavior (and for
   completeness includes the both the cases where the inner label is and
   is not signaled).

     Inner  | 5512  | LSP to    |    Tunnel
     label? | attr? | Next Hop? |    Behavior
     ---------------------------------------------------------
       No   |  No   | No        |   Don't tunnel packet
            |       |           |      (normal behavior without VA)
       No   |  No   | Yes       |   Use LSP
       No   |  Yes  | No        |   Use 5512 tunnel to next hop
       No   |  Yes  | Yes       |   Use 5512 tunnel to Next Hop
            |       |           |      if possible, else use LSP *
       Yes  |  No   | No        |   Use IP tunnel to Next Hop
            |       |           |      with inner label
       Yes  |  No   | Yes       |   Use LSP (stacked labels)
       Yes  |  Yes  | No        |   Use 5512 tunnel to Next Hop
            |       |           |      with inner label
       Yes  |  Yes  | Yes       |   Use 5512 tunnel to Next Hop
            |       |           |      with inner label if possible,
            |       |           |      else use LSP *

       * If the receiving router does not have the appropriate 5512
         tunneling capability (IP or GRE), and it does have LSP
         capability, then it should use the LSP.

   It is important to note that conveying inner label or tunneling
   information in BGP is not a negotiation per se: there is no assurance
   that the recipient of the information can actually do the type of
   tunneling indicated.  It is therefore necessary for the AS
   administrator to insure that routers are capable of acting on any



Xu & Francis             Expires March 27, 2010                 [Page 4]

 
Internet-Draft                VA MPLS Label               September 2009


   labeling or tunneling information that they receives.

1.1.  Requirements notation

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

1.2.  Changes from Previous Versions

   This is the first version of this draft.


.  IANA Considerations

   There are no IANA considerations.


.  Security Considerations

   Because this document describes a standard application of MPLS, there
   are no new security considerations beyond those already described in
   [I-D.ietf-grow-va-mpls].  It is worth noting, however, that the some
   of the security considerations normally associated with VPNs, namely
   that it not be possible for a non-VPN source to inject a packet into
   a VPN, do not apply here.  Virtual Aggregation applies to global
   routing, not to VPN, and therefore it is not necessary to isolate
   communities.


.  Normative References

   [I-D.ietf-grow-va-gre]
              Francis, P., Raszuk, R., and X. Xu, "GRE and IP-in-IP
              Tunnels for Virtual Aggregation",
              draft-ietf-grow-va-gre-00 (work in progress), July 2009.

   [I-D.ietf-grow-va-mpls]
              Francis, P. and X. Xu, "MPLS Tunnels for Virtual
              Aggregation", draft-ietf-grow-va-mpls-00 (work in
              progress), May 2009.

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

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.



Xu & Francis             Expires March 27, 2010                 [Page 5]

 
Internet-Draft                VA MPLS Label               September 2009


   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
              MPLS in IP or Generic Routing Encapsulation (GRE)",
              RFC 4023, March 2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC5512]  Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
              BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.


Authors' Addresses

   Xiaohu Xu
   Huawei Technologies
   No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
   Beijing, Beijing  100085
   P.R.China

   Phone: +86 10 82836073
   Email: xuxh@huawei.com


   Paul Francis
   Max Planck Institute for Software Systems
   Gottlieb-Daimler-Strasse
   Kaiserslautern  67633
   Germany

   Email: francis@mpi-sws.org


















Xu & Francis             Expires March 27, 2010                 [Page 6]