Internet Draft Document                                    Michael Mroz
draft-mroz-ppvpn-inter-as-lsps-00.txt                       Olen Stokes
                                              Venkatesh Kanagasabapathy
                                                        Vijay Bhagavath
                                                       Extreme Networks

                                                            Giles Heron
                                                   PacketExchange, Ltd.

                                                             Pierre Lin
                                             Yipes Communications, Inc.

                                                          Yetik Serbest
                                                     SBC Communications

Expires August 2002                                       February 2002



       Tunnel LSPs Extended Across Autonomous System Boundaries



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 document describes the usage of the Border Gateway Protocol
     (BGP)  to establish Transparent LAN Services (TLS) tunnels across
     Autonomous System (AS) boundaries. TLS is described in [MARTINI-
     SIG] and [LASSERRE-TLS]. The focus of this document is to explain
     how to achieve the tunnel LSP between Provider Edge (PE) routers in
     different ASes. The method described herein may also be used in
     [BGP-VPN] implementations.


Mroz, et al.                                                   [Page  1]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002

Conventions

     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.


Placement of this Memo in Sub-IP Area


RELATED DOCUMENTS

     http://search.ietf.org/internet-drafts/draft-martini-l2circuit-
     trans-mpls-06.txt

     http://search.ietf.org/internet-drafts/draft-lasserre-vkompella-
     ppvpn-vpls-00.txt

     http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-
     00.txt

WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK

     PPVPN

WHY IS IT TARGETTED AT THIS WG

     The charter of the PPVPN WG includes L2 VPN services and this draft
     specifies a method for extending Ethernet L2 VPN services over MPLS
     across AS boundaries.

JUSTIFICATION

     There is no Internet document that fully provides a method of
     establishing inter-AS LSPs, which are necessary for the purpose of
     allowing multiple carriers to be involved in a single L2VPN.


















Mroz, et al.                                                   [Page  2]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


Table of Contents


1       Overview .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 4
1.1     Labeled Route Known Within the AS.  .  .  .  .  .  .  .  .  . 5
1.2     Labeled Route Not Known Within the AS  .  .  .  .  .  .  .  . 5
1.3     Terminology .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 6
2       Usage of RFC 3107 .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 6
2.1     MP_REACH_NLRI Next Hop Field  .  .  .  .  .  .  .  .  .  .  . 6
2.2     Multiple Routes to a Destination .  .  .  .  .  .  .  .  .  . 7
2.3     Usage of Labeled Routes .  .  .  .  .  .  .  .  .  .  .  .  . 7
2.4     LSP Between BGP Peers.  .  .  .  .  .  .  .  .  .  .  .  .  . 7
2.5     Label Stack Depth .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 8
3       Usage of RFC 2858 .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 8
3.1     Usage of Sub Network Point of Attachment  .  .  .  .  .  .  . 8
4       Establishing the LSP Between PEs .  .  .  .  .  .  .  .  .  . 8
4.1     BGP Next Hop Reachability  .  .  .  .  .  .  .  .  .  .  .  . 9
4.2     PE Reachability.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 9
5       Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 9
6       Scalability Issues.  .  .  .  .  .  .  .  .  .  .  .  .  .  . 9
7       Intellectual Property Considerations.  .  .  .  .  .  .  .  .10
8       Full Copyright Statement.  .  .  .  .  .  .  .  .  .  .  .  .10
9       References  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .11
10      Authors' Addresses.  .  .  .  .  .  .  .  .  .  .  .  .  .  .12
11      Appendix A: Example of Establishment of Inter-AS LSP  .  .  .13
12      Appendix B: Example of an Update Message Containing MP REACH
              NLRI  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .16


























Mroz, et al.                                                   [Page  3]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002



1    Overview

     This document describes a method of establishing Label Switched
     Paths (LSP, see [MPLS]) between Provider Edge (PE) devices that are
     located in different Autonomous Systems (AS). This document also
     resolves some ambiguities with respect to [SDP] when carrying
     labeled IPv4 routes. The intent is to enable VPN services to be
     delivered over multiple provider networks. For example, multipoint
     metro Ethernet (VPLS [L2VPN]) services can be offered on a global
     scale, over multiple metro and wide-area networks. VPLS
     capabilities support applications such as enterprise LAN
     interconnection, distance peering, Internet access and virtual co-
     location.

     There is currently one other IETF document ([INTER-CITY]) that
     provides a method of establishing inter-AS LSPs. [INTER-CITY] does
     not address the ambiguities with respect to [SDP] that are
     mentioned above.

     Other documents have suggested methods of establishing inter-AS
     LSPs. For example, [BGP-VPN] briefly describes three methods of
     setting up LSPs on inter-provider backbones. Also, [L2VPN]
     recommends using the most scalable method described in [BGP-VPN].
     This method will be the focus herein.

     [MARTINI-SIG] uses targeted Label Distribution Protocol (LDP, see
     [MPLS-LDP]) sessions to distribute Virtual Circuit (VC) labels
     between the PE. Similarly, a [BGP-VPN] or [L2VPN] implementation
     may use multi-hop EBGP sessions to distribute labeled VPN-IPv4
     routes between the PEs. The labels in the above cases are referred
     to as "VPN labels". In data packets, the MPLS label stack above the
     related VPN label is used to "tunnel" these packets through the
     MPLS network between the PEs. The simplest case is where the
     related tunnel LSP is set up within an AS by LDP. When multiple
     ASes are involved, LDP does not normally distribute labels across
     AS boundaries. Instead, BGP is used to distribute "labeled /32 IPv4
     routes to the PE routers" as specified in [SDP].

     This document focuses on the use of [MPLS-LDP] for establishment of
     LSPs that are interior to an AS. It is, however, reasonable that
     other protocols such as that described in [RSVP-TE] could be used.

     There are two cases for inter-AS tunnel LSP construction. In the
     first case, the AS Border Router (ASBR) that receives the "labeled
     /32 IPv4 route to the PE" imports it into its own AS, which implies
     that the PEs need not run BGP at all. In the second case, the
     routes are not available in the Interior Gateway Protocol (IGP)
     running within the AS.




Mroz, et al.                                                   [Page  4]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002



1.1  Labeled Route Known Within the AS

     When the "labeled /32 routes to the PE" are known internally to all
     ASes through which the tunnel LSP must pass, a "single label" stack
     is sufficient to transport packets from one PE to another. Assume
     that PE1 and PE2 wish to exchange VPN labels. In the first AS (AS1)
     containing PE1, a route to PE1 and an LSP to follow that route
     would be available to an ASBR. That ASBR (call it ASBR1) would be
     configured to use BGP to export a "labeled /32 IPv4 route to PE1"
     to its EBGP neighbor. The neighbor ASBR would be configured to
     import the route into its own AS. This would continue until the AS
     that contained PE2 received the route, at which time PE2 would be
     able to use VPN labels distributed by PE1.

     The route to PE1 exported by ASBR1 has an association to an LSP
     that was formed by LDP within AS1. Since LDP does not operate
     between AS1 and other ASes, ASBR1's BGP must allocate a label to
     assign to the route to get to PE1 and distribute the related
     "labeled /32 IPv4 route to PE1" to its neighbor. Within its
     forwarding database, ASBR1 will arrange for a label swap from the
     label assigned by BGP for the "labeled /32 IPv4 route to PE1" to
     the label received via LDP for the route. Connecting LDP-
     distributed LSPs to consequently generated LSPs formed by BGP is
     known as an "export splice". Similarly, the neighboring ASBR will
     receive the "labeled /32 IPv4 route to PE1" and will import this
     route into its own AS, causing LDP to distribute a label for the
     route. Within its forwarding database, that ASBR will arrange for a
     label swap from the label received in the "labeled /32 IPv4 route
     to PE1" to the label assigned by LDP for the route. Connecting BGP-
     distributed LSPs to consequently generated LSPs formed by LDP is
     known as an "import splice".

1.2  Labeled Route Not Known Within the AS

     When the BGP labeled /32 routes to the PEs are not imported into
     the ASes, the tunnel LSP between the PEs must be set up using a
     "two label" stack. The top label, distributed by LDP, is used to
     get a packet to the BGP Next Hop of the route. The bottom label is
     assigned and distributed by the BGP Next Hop in the related
     "labeled /32 IPv4 route to the PE". Label swaps are performed on
     the top label by Label Switching Routers (LSR) internal to the AS.
     The penultimate LSR (the ASBR in the AS) may swap this label for
     the Implicit Null label before sending the packet to its exterior
     neighboring ASBR. The exterior ASBR, having assigned the bottom
     label, can now recognize the need to swap this label for the one
     assigned by the next BGP Next Hop, and to push a label associated
     to an LSP used within the AS to get to that BGP Next Hop.





Mroz, et al.                                                   [Page  5]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002



1.3  Terminology

     The phrase "labeled IPv4 route to x" is used when referring to BGP
     routes sent or received in MP REACH NLRI attributes.

     The phrase "distribute a route to X and a label" is used to mean
     that the IGP will distribute the route and LDP will distribute a
     label for that route.

     The use of the term "import" means "to accept external information
     into a domain", and is consistent with its usage in [OSPF]. The
     term "export" means "to provide information to the exterior of a
     domain".

2    Usage of RFC 3107

     [SDP] describes the format used by BGP that allows it to distribute
     labeled routes. The following sections specify some usages of the
     formats in [SDP] for distributing labeled IPv4 routes.

2.1  MP_REACH_NLRI Next Hop Field

     When used in the context of [SDP], the format of the MP_REACH_NLRI
     Next Hop field (see [MEXT-BGP4]) does not contain a field for an
     MPLS label. Consequently, in this application, the MP_REACH_NLRI
     Next Hop contains an unlabeled IPv4 address, as does the NEXT HOP
     attribute (see [BGP-4}).

     The formats given in [SDP] allow multiple routes to the same
     destination to be carried in a single Update message. The format
     restricts all of the labeled prefixes to have the same BGP Next
     Hop, but does not restrict an unlabeled route from carrying a
     different BGP Next Hop (in the NEXT_HOP attribute).  This would be
     expected since [SDP] does not restrict the address family to IPv4.
     However, [BGP-4] states that an Update message carries a single
     route, yet allows multiple prefixes to share the route's
     attributes. When the MP REACH NLRI carries labeled IPv4 addresses,
     the NEXT_HOP attribute, if present, SHALL contain the same prefix
     as the Next Hop field of the MP_REACH_NLRI attribute (note,
     although the NEXT HOP attribute is a mandatory attribute,
     [MEXT-BGP4] allows it to be excluded when the NLRI field of the
     Update is empty).

     An example BGP Update message that contains labeled IPv4 routes is
     given in Appendix B.







Mroz, et al.                                                   [Page  6]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


2.2  Multiple Routes to a Destination

     It can be inferred from [SDP] that a single Update message can
     carry multiple routes to the same destination as long as each route
     carries a different label. However, doing so assigns the same BGP
     attribute values to all such routes. Furthermore, there is no tie-
     breaking procedure defined among such routes. Therefore, a single
     Update message SHALL carry a particular address prefix only once,
     either in the NLRI field (without a label) or in the MP REACH NLRI
     field (with a label). Each route to a particular destination and
     from the same BGP speaker SHALL be delivered in a separate Update
     message.

     Withdrawal of routes to a prefix is done either using the standard
     Withdrawn Routes field when unlabeled IPv4 routes are to be
     withdrawn, or by using the MP UNREACH NLRI attribute when labeled
     IPv4 routes are to be withdrawn. In the latter case, a specific
     labeled IPv4 route is withdrawn by specifying the label originally
     provided. All labeled IPv4 routes with the same prefix and from the
     same BGP speaker are withdrawn when the specified label value is
     0x800000 (the unlabeled route, if any, is not affected).

     This document does not require that an implementation support the
     Multiple Routes to a Destination feature.

2.3  Usage of Labeled Routes

     A labeled IPv4 route can only be used to forward traffic via MPLS.
     A router MUST NOT install this route in such a way that forwarding
     takes place without using the related label switched path.

2.4  LSP Between BGP Peers

     [SDP] indicates that a BGP speaker should not advertise the
     capability to exchange labeled routes to its peer unless there is
     an LSP between them. However, if the speakers are directly
     adjacent, the LSP could be established by exchanging labeled IPv4
     routes once the capability has been advertised.















Mroz, et al.                                                   [Page  7]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002



2.5  Label Stack Depth

     An MP REACH NLRI attribute can carry labeled IPv4 routes that
     contain more than one label, with the final label in the stack
     terminated using the "bottom-of-stack" bit (see [MPLS-ENCAPS]). The
     format of the NLRI field of the MP REACH NLRI attribute limits the
     depth of the label stack associated to an address prefix (to nine
     labels for labeled IPv4). However, it may be reasonable for an
     implementation to further limit this depth.

     An implementation that receives a labeled IPv4 route whose label
     stack depth exceeds the maximum depth tolerated by that
     implementation SHALL reject the route, sending a Notify containing
     the Optional Attribute Error subcode to the peer that sent the
     route (see [BGP-4]).


3    Usage of RFC 2858

3.1  Usage of Sub Network Point of Attachment

     Usage of the SNPA field of the MP REACH NLRI attribute is not
     specified herein. The "Number of SNPAs" field may be set to zero.


4    Establishing the LSP Between PEs

     If routes to the PE routers are to be known within those ASes
     across which an LSP must be set up, ASBRs will have to be
     configured to import and export "labeled /32 IPv4 routes to PEs" to
     and from their respective IGP. It should be noted that not all ASes
     need to be configured the same way. For example, a transit AS may
     be configured not to import routes to the PEs, while the AS
     containing the PE devices may be configured otherwise.

     The remaining subsections are devoted to the case where routes to
     PE routers are not known to AS-internal routers that do not run
     BGP. It is assumed that the PE routers are running BGP and are
     exchanging labeled IPv4 routes with their peers. Appendix A gives
     an example of an inter-AS LSP setup.












Mroz, et al.                                                   [Page  8]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


4.1  BGP Next Hop Reachability

     In order to reach inter-AS destinations of routes distributed with
     labels, there must be an LSP to get to the BGP Next Hop of the
     route. The BGP Next Hop of a route would normally be either the
     exterior ASBR that has a non-multihop EBGP session with the
     interior ASBR, or the interior ASBR itself.

     When the BGP Next Hop is the exterior ASBR, the exterior ASBR could
     advertise a "labeled /32 IPv4 route to itself" to the interior
     ASBR, and the interior ASBR could be configured to import that
     route into its AS routing domain. Alternatively, the interior ASBR
     could proxy-advertise a /32 route and a label to its interior AS,
     and arrange for a label swap to the Implicit Null label.

     When the BGP Next Hop is the interior ASBR (known as "next hop
     self"), the ASBR advertises into its interior a /32 route to
     itself, and also distributes a label for that route into its
     interior.

4.2  PE Reachability

     Because routes to the PEs are not advertised into the interior of
     some ASes along the tunnel LSP, a PE will need to advertise a
     "labeled /32 IPv4 route to itself" (with the next hop of the route
     being the PE itself) to its peers. As with the "next hop self" case
     described above, the PE must also advertise a route to itself and
     distribute a label for that route into its interior.

     The advantage of having the PE advertise the "labeled /32 IPv4
     route to itself" is that the ASBR will not have to be configured to
     export the route to the PE from its interior.

     Alternatively, the interior ASBR could be configured as such. If
     the interior ASBR were also configured to imported a route and a
     label to the remote PE, the local PE would not have to run BGP.

5    Security Considerations

     No new security issues result from this document.



6    Scalability Issues

     In [MARTINI-SIG], targeted LDP sessions are used to distribute VPN
     labels. Because the related TCP sessions will now be established
     between ASes, the same scalability problems faced by BGP (addressed
     using Route Reflectors [BGP-RR] and/or Confederations [BGP-CONFED])
     could arise. Since the focus of this document is to provide a
     method for establishing inter-AS LSPs, this issue will not be
     addressed further.

Mroz, et al.                                                   [Page  9]

Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002



7    Intellectual Property Considerations

     This document is being submitted for use in IETF standards
     discussions.


8    Full Copyright Statement

     Copyright (C) The Internet Society (2002).  All Rights Reserved.
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into languages
     other than English.

     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




















Mroz, et al.                                                   [Page 10]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


9    References

     [BGP-VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-00.txt (Work
     In Progress)

     [L2VPN] "Layer 2 VPNs Over Tunnels", draft-kompella-ppvpn-l2vpn-
     01.txt (Work In Progress)

     [SDP] Rekhter & Rosen, "Carrying Label Information in BGP-4", RFC
     3107, May 2001

     [LASSERRE-TLS] "Transparent VLAN Services over MPLS", draft-
     lasserre-vkompella-ppvpn-vpls-00.txt, May 2002 (Work In Progress)

     [MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft-
     martini-l2circuit-trans-mpls-08.txt, November 2001 (Work IN
     Progress)

     [BGP-4] Rekhter & Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
     1771, March 1995

     [MEXT-BGP4] Bates, et al., "Multiprotocol Extensions for BGP-4",
     RFC 2858, June 2000

     [MPLS] Rosen, et al., "Multiprotocol Label Switching Architecture",
     RFC 3031, January 2001

     [MPLS-LDP] Andersson, et al., "LDP Specification", RFC 3036,
     January 2001

     [RSVP-TE] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
     Tunnels", RFC 3209, December 2001

     [OSPF] Moy, "OSPF Version 2", RFC 2328, April 1998

     [BGP-RR] Bates, et al., "BGP Route Reflection - An Alternative to
     Full Mesh IBGP", RFC 2796, April 2000

     [BGP-CONFED] Traina, et al., "Autonomous System Confederations for
     BGP", RFC 3065, February 2001

     [MPLS-ENCAPS] Rosen, et al., "MPLS Label Stack Encoding", RFC 3032,
     January 2001

     [INTER-CITY] Menezes, et al., "Inter-City MAN Services Using MPLS",
     draft-menezes-inter-city-man-mpls-00.txt, November 2001







Mroz, et al.                                                   [Page 11]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


10    Authors' Addresses

     Mike Mroz
     Extreme Networks
     630 Davis Drive, Suite 250
     Morrisville, NC 27560
     Email: mroz@extremenetworks.com

     Olen Stokes
     Extreme Networks
     630 Davis Drive, Suite 250
     Morrisville, NC 27560
     Email: ostokes@extremenetworks.com

     Venkatesh Kanagasabapathy
     Extreme Networks
     3585 Monroe Street
     Santa Clara, CA 95051
     Email: vkanagasabapathy@extremenetworks.com

     Vijay Bhagavath
     Extreme Networks
     3583 Monroe Street
     Santa Clara, CA 95051
     Email: vbhagavath@extremenetworks.com

     Giles Heron
     PacketExchange, Ltd.
     91 Brick Lane
     London E1 6QL
     U.K.
     Email: giles@packetexchange.net

     Pierre Lin
     Yipes Communications, Inc.
     114 Sansome St.
     San Francisco CA 94104
     Email: pierre.lin@yipes.com

     Yetik Serbest
     SBC Communications
     Austin, TX
     Email: serbest@tri.sbc.com
     512-372-5666









Mroz, et al.                                                   [Page 12]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


11   Appendix A: Example of Establishment of Inter-AS LSP

     The following example refers to Figure A.1.


                               <-------------

      ------------  L32'         ---------  L32          ------------
     |   ASBR31   |-------------|   P3    |-------------|   ASBR32   |
      ------------          L31  ---------          L31' ------------
            |    L12                                           |    L22
            |                   ------------>                  |
            |                       AS3                        |
------------+--------------------------------------------------+-------
            |  NULL               |      |                     | NULL
      NULL  |                     |      |                NULL |
      ------------                |      |               ------------
L22' |   ASBR1    |               |      |         L12' |   ASBR2    |
      ------------                |      |               ------------
            |   L11'              |      |                     |   L21'
       L23  |                     |      |               L13   |
      ------------                |      |               ------------
     |     P1     |               |      |              |     P2     |
      ------------                |      |               ------------
            |   L11               |      |                     |   L21
       L23' |                     |      |               L13'  |
L22'' ------------                |      |         L12'' ------------
L24  |     PE1    |               |      |         L14  |     PE2    |
      ------------                |      |               ------------
            |                     |      |                     |
            |              AS1    |      |   AS2               |
            |                     |      |                     |
------------+---------------------|      |---------------------+-------
            |                     |      |                     |
            |                     |      |                     |
         -------                  |      |                  -------
        /  CE1  \                 |      |                 /  CE2  \
        | VLAN1 |                 |      |                 | VLAN2 |
        \       /                 |      |                 \       /
         -------                  |      |                  -------



     Figure A.1: Establishment of Inter-AS LSP Between PE1 and PE2









Mroz, et al.                                                   [Page 13]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


     In the figure, AS1 and AS2 contain PE devices, and AS3 is a transit
     network. Labels inside the "horseshoe" are used for data flow from
     CE1 to CE2, and labels outside the horseshoe are used for dataflow
     from CE2 to CE1 (arrows indicate these directions). All ASes are
     running [OSPF] as their IGP, and are running LDP. All devices
     except the Provider (Pn) internal devices are running BGP. PE1 and
     PE2 are running the protocol described in [MARTINI-SIG]. It is
     assumed that the EBGP sessions may advertise the multiprotocol
     capability for labeled IPv4 routes before an LSP is established
     between the related ASBRs. An LSP establishment sequence follows:

1.   ASBR1 proxy advertises into AS1 (via OSPF) a /32 route to get to
     ASBR31. LDP running in ASBR1 advertises a label (L11') into AS1
     for that route. P1's LDP advertises label L11 for the route.
     Similarly, ASBR2 proxy advertises a route and label (L21') for
     ASBR32 into AS2 and P2's LDP advertises label L21 for the route;
     ASBR32 advertises L31' for ASBR2 into AS3 and P3 advertises L31;
     and ASBR31 advertises L32' for ASBR1 into AS3 and P3 advertises
     L32. In this way, LSPs to the BGP Next Hops are known in the
     relevant AS interior. When doing this advertisement, each device
     arranges for a label swap to the Implicit Null label.
2.   PE1 advertises (via OSPF) a /32 route to itself into AS1. LDP
     distributes a label L23' for that route. P1 consequently
     advertises label L23 to ASBR1 for that route. Similarly, PE2
     advertises label L13' and P2 advertises L13.
3.   PE1 uses BGP to advertise a "labeled /32 IPv4 route to PE1"
     (L22'') to ASBR1. Similarly, PE2 advertises a "labeled /32 IPv4
     route to PE2" (L12'') to ASBR2.
4.   ASBR1 advertises the "labeled /32 IPv4 route to PE1 (L22')" to
     ASBR31 with ASBR1 as the next hop. Similarly, ASBR2 advertises
     the "labeled /32 IPv4 route to PE2 (L12')" to ASBR32 with ASBR2
     as the next hop.
5.   ASBR31 advertises the "labeled /32 IPv4 route to PE1 (L22')" to
     ASBR32. Similarly, ASBR32 advertises the "labeled /32 IPv4 route
     to PE2 (L12')" to ASBR31.
6.   ASBR32 advertises the "labeled /32 IPv4 route to PE1 (L22)" to
     ASBR2 with ASBR32 as the next hop. Similarly, ASBR31 advertises
     the "labeled /32 IPv4 route to PE2 (L12)" to ASBR1 with ASBR31
     as the next hop.
7.   ASBR1 advertises the "labeled /32 IPv4 route to PE2 (L12)" to
     PE1. Similarly, ASBR2 advertises the "labeled /32 IPv4 route to
     PE1 (L22)" to PE2.
8.   PE1 and PE2 establish their targeted LDP session. PE1 advertises
     VC Label L24 for VLAN1 to PE2. PE2 advertises VC Label L14 for
     VLAN2 to PE1.








Mroz, et al.                                                   [Page 14]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


Summary of the elemental LSPs formed above:

     LSP            Created   From    To       Purpose
     ---            -------   ----    --       -------
     L11-L11'-NULL  LDP       PE1     ASBR31   BGP Next Hop
     L31-L31'-NULL  LDP       ASBR31  ASBR2    BGP Next Hop
     L13-L13'       LDP       ASBR2   PE2      BGP Next Hop
     L12-L12'-L12'' BGP       PE1     PE2      Identifies Next Hop LSP
     L14            LDP       PE1     PE2      Identifies VLAN2
     L21-L21'-NULL  LDP       PE2     ASBR32   BGP Next Hop
     L32-L32'-NULL  LDP       ASBR32  ASBR1    BGP Next Hop
     L23-L23'       LDP       ASBR1   PE1      BGP Next Hop
     L22-L22'-L22'' BGP       PE2     PE1      Identifies Next Hop LSP
     L24            LDP       PE2     PE1      Identifies VLAN1

     Label Stacks Formed for Figure A.1 are read from (left) top of
     stack to (right) bottom of stack (i.e., Top/Middle/Bottom). The
     stacks are shown as they exist on the links between network
     devices.

     Packet From CE1 to CE2               Packet From CE2 to CE1
     ----------------------               ----------------------
     CE1-PE1       None                   CE2-PE2       None
     PE1-P1        L11/L12/L14            PE2-P2        L21/L22/L24
     P1-ASBR1      L11'/L12/L14           P2-ASBR2      L21'/L22/L24
     ASBR1-ASBR31  L12/L14                ASBR2-ASBR32  L22/L24
     ASBR31-P3     L31/L12'/L14           ASBR32-P3     L32/L22'/L24
     P3-ASBR32     L31'/L12'/L14          P3-ASBR31     L32'/L22'/L24
     ASBR32-ASBR2  L12'/L14               ASBR31-ASBR1  L22'/L24
     ASBR2-P2      L13/L12''/L14          ASBR1-P1      L23/L22''/L24
     P2-PE2        L13'/L12''/L14         P1-PE1        L23'/L22''/L24
     PE2-CE2       None                   PE1-CE1       None


     In the forwarding of the packet from ASBR31 to P3 that ASBR31
     performs a swap of label L12 for label L12', and then pushes label
     L31 to get to next hop ASBR2.
















Mroz, et al.                                                   [Page 15]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


12   Appendix B: Example of an Update Message Containing MP REACH NLRI

     The example message carries both the NLRI / NEXT HOP fields and the
     MP REACH NLRI field.

     Octets   Data              Description
     ------   ----              -----------
      0-15    FF...FF           Marker (all ones)
     16-17    0052              Length (82 octets)
     18       02                Type (UPDATE)
     19-20    0000              Unfeasible routes (length)
     21-22    0033              Path Attribute Length, 51 octets
     23-24    4001              ORIGIN Attribute
     25       01                Length of ORIGIN attribute value
     26       01                NLRI learned via EGP
     27-28    4002              AS PATH Attribute
     29       04                Length of AS PATH
     30       01                AS_SET
     31       01                One AS is present
     32-33    FC00              Private AS number
     34-35    4003              NEXT HOP Attribute
     36       04                Length of Next Hop
     37-38    0A320101          Next hop is 10.50.1.1
     39-40    4005              LOCAL PREF Attribute
     41       04                Length of local preference
     42-43    00000005          Local Preference Metric

     Labeled IPv4 routes are contained in MP REACH NLRI attribute:

     44-45    800E              MP REACH NLRI Attribute
     46       1B                MP REACH NLRI Attribute length 27
     47-48    0800              Address Family is IP
     49       04                SAFI is RFC3107, label present
     50       04                Length in octets of Next Hop
     51-54    0A320101          Next hop is 10.50.1.1
     55       00                No SNPAs are present
     56       38                Length of label/prefix (56 bits)
     57-59    CEC001            Label CEC00 (Bottom-of-stack)
     60-63    0A3C0101          IP network 10.60.1.1/32
     64       48                Length of label/prefix (72 bits)
     65-67    473200            Label 47320
     68-70    473211            Label 47321 (Bottom-of-stack)
     71-73    0A4601            IP network 10.70.1.0/24

     Unlabeled routes are contained in the normal Update NLRI field:

     74       18                Length of 1st NLRI (24 bits)
     75-77    0A5001            Prefix 10.80.1/24
     78       14                Length of last NLRI (20 bits)
     79-81    0A2810            Prefix 10.40.16/20



Mroz, et al.                                                   [Page 16]


Internet Draft draft-mroz-ppvpn-inter-as-lsps-00.txt       February 2002


     Some notes on the Example Update message:

1.   Four address prefixes are present, two with labels, and two
     without. No withdrawn routes are present, and for simplicity,
     a minimal set of attributes is present. IP addresses were
     selected from the private address space for the example.
2.   There is a two-deep label stack associated to the prefix
     10.70.1.0/24. The reason for this is beyond the scope of this
     document. However, an implementation that normally associates
     only a single label to a prefix and which is to become the
     Next Hop for the advertised route could assign and distribute
     a single label, and arrange to swap this label for the two
     label stack.
3.   The "labeled /32 IPv4 route to 10.60.1.1" could be a route to
     get to PE1 in Figure A.1. The Update message could be one
     sent from ASBR31 to ASBR32 via IBGP as described in bullet 5
     of Appendix A.




































Mroz, et al.                                                   [Page 17]