L1VPN Working Group                            Hamid Ould-Brahim
     Internet Draft                                         Don Fedyk
     Intended status: Standards Track                          Nortel
     Expires: July 2008
                                                        Yakov Rekhter
                                                     Juniper Networks

                                                         January 2008



                      BGP-based Auto-Discovery for L1VPNs


                   draft-ietf-l1vpn-bgp-auto-discovery-03.txt


     Status of this Memo

        By submitting this Internet-Draft, each author represents that
        any applicable patent or other IPR claims of which he or she is
        aware have been or will be disclosed, and any of which he or
        she becomes aware will be disclosed, in accordance with Section
        6 of 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.


     Abstract

        The purpose of this draft is to define a BGP-based auto-
        discovery mechanism for layer-1 VPNs. The auto-discovery
        mechanism for l1vpns allows the provider network devices to

     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 1]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        dynamically discover the set of PEs having ports attached to CEs
        member of the same VPN. That information is necessary for
        completing the signaling phase. One main objective of l1vpn
        auto-discovery mechanism is to support "single-end provisioning"
        model, where addition of a new port to a given l1vpn would
        involve configuration changes only on the PE that has this port
        and on the CE that is connected to the PE via this port.

     1. Introduction

        The purpose of this draft is to define a BGP-based auto-
        discovery mechanism for layer-1 VPNs [L1VPN-FRMK]. The auto-
        discovery mechanism for l1vpns allows the provider network
        devices to dynamically discover the set of PEs having ports
        attached to CEs member of the same VPN. That information is
        necessary for completing the signaling phase. One main objective
        of l1vpn auto-discovery mechanism is to support "single-end
        provisioning" model, where addition of a new port to a given
        l1vpn would involve configuration changes only on the PE that
        has this port and on the CE that is connected to the PE via this
        port.


        The auto-discovery mechanism proceeds by having a PE advertises
        to other PEs, at a minimum, its own IP address and the list of
        <private address, provider address> tuples local to that PE.
        Once that information is received, the remote PEs will identify
        the list of VPN members they have in common with the advertising
        PE, and use the information carried within the discovery
        mechanism to perform address resolution during signaling phase.



















     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 2]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


                        PE1                        PE2
                    +---------+             +--------------+
        +--------+  | +------+|             | +----------+ | +-------+
        |  VPN-A |  | |VPN-A ||             | |  VPN-A   | | |  VPN-A |
        |   CE1  |--| |PIT   ||  BGP route  | |  PIT     | |-|   CE2  |
        +--------+  | |      ||<----------->| |          | | +--------+
                    | +------+| Distribution| +----------+ |
                    |         |             |              |
        +--------+  | +------+|             | +----------+ | +--------+
        | VPN-B  |  | |VPN-B ||  --------   | |   VPN-B  | | |  VPN-B |
        |  CE1   |--| |PIT  ||-(   GMPLS )--| |   PIT    | |-|   CE2  |
        +--------+  | |      || (Backbone ) | |          | | +--------+
                    | +------+|  ---------  | +----------+ |
                    |         |             |              |
        +--------+  | +-----+ |             | +----------+ | +--------+
        | VPN-C  |  | |VPN-C| |             | |   VPN-C  | | |  VPN-C |
        |  CE1   |--| |PIT  | |             | |   PIT    | |-|   CE2  |
        +--------+  | |     | |             | |          | | +--------+
                    | +-----+ |             | +----------+ |
                    +---------+             +--------------+
                 Figure 1 Figure 1 BGP auto-discovery for l1vpn

        This version of the draft focuses on describing an auto-
        discovery mechanism for the basic mode only. Details for the
        enhanced mode will be described in future revised version of
        this draft.

     2. Procedures

        In the context of l1vpns, a CE is connected to a PE via one or
        more ports, where each port may consists of one or more channels
        or sub-channels. Each port on a CE that connects the CE to a PE
        has an identifier that is unique within that l1vpn (but need not
        be unique across several l1vpn). We refer to this identifier as
        the customer port identifier (CPI). Each port on a PE has as
        well an identifier that is unique within that provider network.
        We refer to this identifier as the provider port identifier
        (PPI). Note that IP addresses used for CPIs, PPIs could be
        either IPv4 or IPv6 addresses.

        A PE maintains for each l1vpn configured on that PE a port
        information tables (PIT) associated with each l1vpn that has at
        least one port configured on a PE. A PIT contains a list of
        <CPI, PPI> tuples for all the ports within its l1vpn. Note that
        a PIT may as well hold routing information (for example when
        CPIs are learnt using a routing protocol).



     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 3]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        A PIT on a given PE is populated from two sources: the
        information related to the CEs? ports attached to the ports on
        that PE (this information could be optionally received from the
        CEs), and the information received from other PEs through the
        auto-discovery mechanism. We?ll refer to the former as the
        "local" information, and to the latter as the "remote"
        information.

        Propagation of local information to other PEs is accomplished by
        using BGP multiprotocol extensions. To restrict the flow of this
        information to only the PITs within a given l1vpn, we use BGP
        route filtering based on the Route Target Extended Community
        [BGP-COMM], as follows.

        Each PIT on a PE is configured with one or more Route Target
        Communities, called "export Route Targets", that are used for
        tagging the local information when it is exported into
        provider's BGP. The granularity of such tagging could be as fine
        as a single <CPI, PPI> pair. In addition, each PIT on a PE is
        configured with one or more Route Target Communities, called
        "import Route Targets", that restrict the set of routes that
        could be imported from provider's BGP into the PIT to only the
        routes that have at least of these Communities.

        When a service provider adds a new l1vpn port to a particular
        PE, this port is associated at provisioning time with a PIT on
        that PE, and this PIT is associated (again at provisioning time)
        with that l1vpn.

        Note that since the protocol used to populate a PIT with remote
        informa

        tion is BGP, since BGP works across multiple routing domains, it
        follows that the mechanisms described in this document could
        support l1vpns that span multiple routing domains.

     3. Carrying l1vpn information in BGP

        The <CPI, PPI> mapping is carried using the Multiprotocol
        Extensions BGP [RFC4760]. [RFC4760] defines the format of two
        BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be
        used to announce and withdraw the announcement of reachability
        information. We introduce a new a new subsequent address family
        identifier (to be assigned by the IANA), and also a new NLRI
        format for carrying the CPI and PPI information.

        One or more <PPI, CPI> tuples could be carried in the above
        mentioned BGP attributes.

     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 4]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        The format of the NLRI is described in figure 2.



                     +---------------------------------------+

                     |     Length (1 octet)                  |

                     +---------------------------------------+

                     |     Auto-discovery info (variable)    |

                     +---------------------------------------+

                         Figure 2 Encoding of the NLRI

        The encoding of the auto-discovery infromation is described in
        [L1VPN-BM].

        Note that if the value of the Length of the Next Hop field is 4,
        then the Next Hop contains an IPv4 address. If this value is 16,
        then the Next Hop contains an IPv6 address.

     4. Carrying L1VPN Traffic Engineering Information in BGP

        In addition to reachability information, the auto-discovery
        mechanism may carry Traffic Engineering information that will be
        used for signaling purposes. For example a PE may learn from the
        remote PEs, the switching capability, the maximum LSP bandwidth
        of the remote l1vpn interfaces. This document proposes the use
        of the BGP attribute defined in [BGP-TE-ATTRIBUTE] to carry such
        information.

     5. Scalability


        Recall that the Service Provider network consists of (a) PE, (b)
        BGP Route Reflectors, (c) P nodes (which are neither PEs nor
        Route Reflectors), and, in the case of multi-provider VPNs, (d)
        ASBRs.

        A PE router, unless it is a Route Reflector should not retain
        L1VPN-related information unless it has at least one VPN with an
        Import Target identical to one of the VPN-related information
        Route Target attributes.  Inbound filtering should be used to
        cause such information to be discarded.  If a new Import Target
        is later added to one of the PE's VPNs (a "VPN Join" operation),


     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 5]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        it must then acquire the VPN-related information it may
        previously have discarded.

        This can be done using the refresh mechanism described in [BGP-
        RFSH]. The outbound route filtering mechanism of [BGP-ORF],
        [BGP-CONS] can also be used to advantage to make the filtering
        more dynamic.

        Similarly, if a particular Import Target is no longer present in
        any of a PE's VPN (as a result of one or more "VPN Prune"
        operations), the PE may discard all VPN-related information
        which, as a result, no longer have any of the PE's VPN Import
        Targets as one of their Route Target Attributes.

        Note that VPN Join and Prune operations are non-disruptive, and
        do not require any BGP connections to be brought down, as long
        as the refresh mechanism of [BGP-RFSH] is used.

        As a result of these distribution rules, no one PE ever needs to
        maintain all routes for all L1VPNs; this is an important
        scalability consideration.

        Route reflectors can be partitioned among VPNs so that each
        partition carries routes for only a subset of the L1VPNs
        supported by the Service Provider. Thus no single route
        reflector is required to maintain VPN-related information for
        all VPNs.

        For inter-provider VPNs, if multi-hop EBGP is used, then the
        ASBRs need not maintain and distribute VPN-related information
        at all. P routers do not maintain any VPN-related information.

        As a result, no single component within the Service Provider
        network has to maintain all the VPN-related information for all
        the VPNs. So the total capacity of the network to support
        increasing numbers of VPNs is not limited by the capacity of any
        individual component.

        An important consideration to remember is that one may have any
        number of INDEPENDENT BGP systems carrying VPN-related
        information. This is unlike the case of the Internet, where the
        Internet BGP system must carry all the Internet routes. Thus one
        significant (but perhaps subtle) distinction between the use of
        BGP for the Internet routing and the use of BGP for distributing
        VPN-related information, as described in this document is that
        the former is not amenable to partition, while the latter is.



     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 6]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


     6. Security Considerations

        This document describes a BGP-based auto-discovery mechanism
        which enables a PE that attaches to a particular L1VPN to
        discover the set of other PE routers that attach to the same
        VPN.  Each PE router that is attached to a given VPN uses BGP to
        advertise that fact. Other PE routers which attach to the same
        VPN receive these BGP advertisements. This allows that set of PE
        to discover each other. Note that a PE will not always receive
        these advertisements directly from the remote PEs; the
        advertisements may be received from "intermediate" BGP speakers.

        It is of critical importance that a particular PE should not be
        "discovered" to be attached to a particular VPN unless that PE
        really is attached to that VPN, and indeed is properly
        authorized to be attached to that VPN.  If any arbitrary node on
        the Internet could start sending these BGP advertisements, and
        if those advertisements were able to reach the PE nodes, and if
        the PE nodes accepted those advertisements, then anyone could
        add any site to any L1VPN.  Thus the auto-discovery procedures
        described here presuppose that a particular PE trusts its BGP
        peers to be who they appear to be, and further that it can
        trusts those peers to be properly securing their local
        attachments.  (That is, a PE must trust that its peers are
        attached to, and are authorized to be attached to, the L1VPNs to
        which they claim to be attached.).

        If a particular remote PE is a BGP peer of the local PE, then
        the BGP authentication procedures of RFC 2385 can be used to
        ensure that the remote PE is who it claims to be, i.e., that it
        is a PE that is trusted.

        If a particular remote PE is not a BGP peer of the local PE,
        then the information it is advertising is being distributed to
        the local PE through a chain of BGP speakers.  The local PE must
        trust that its peers only accept information from peers that
        they trust in turn, and this trust relation must be transitive.
        BGP does not provide a way to determine that any particular
        piece of received information originated from a BGP speaker that
        was authorized to advertise that particular piece of
        information.  Hence the procedures of this document should be
        used only in environments where adequate trust relationships
        exist among the BGP speakers.


     7. IANA Considerations



     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 7]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        New SAFI number to be assigned by IANA for carrying l1vpn
        information in the NLRI.

     8. References

     8.1. Normative References


        [BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., Rekhter, Y.,
                  "Traffic Engineering Attribute", draft-ietf-softwire-
                  bgp-te-attribute-00.txt, work in progress.


        [RFC4760]  Bates, Chandra, Katz, and Rekhter, "Multiprotocol
                  Extensions for BGP4", February 1998, RFC 4760.


        [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic
                  Mode", draft-ietf-l1vpn-basic-mode, work in progress.


     8.2. Informative References


        [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC
                  2918, October 2000.

        [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering
                  Capability for BGP-4", draft-ietf-idr-route-filter-
                  16.txt, Work in Progress.

        [BGP-CONS] Marques, P., et al., "Constrained VPN route
                  distribution", RFC4684.

        [L1VPN-FRMK] Tomonori Takeda, et al., "Framework and
                  Requirements for Layer 1 Virtual Private Networks",
                  RFC4847.

        [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended
                  Communities Attribute",  RFC4360.

     9. Acknowledgment

        We would like to thank Adrian Farrel for the useful comments.




     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 8]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


     10. Author's Addresses

        Hamid Ould-Brahim
        Nortel
        P O Box 3511 Station C
        Ottawa ON K1Y 4H7 Canada
        Phone: +1 (613) 765 3418
        Email: hbrahim@nortel.com

        Yakov Rekhter
        Juniper Networks
        1194 N. Mathilda Avenue
        Sunnyvale, CA 94089
        Email: yakov@juniper.net

        Don Fedyk
        Nortel
        600 Technology Park
        Billerica, Massachusetts
        01821 U.S.A
        Phone: +1 (978) 288 3041
        Email: dwfedyk@nortel.com


     Intellectual Property Statement


        The IETF takes no position regarding the validity or scope of
        any Intellectual Property Rights or other rights that might be
        claimed to pertain to the implementation or use of the
        technology described in this document or the extent to which any
        license under such rights might or might not be available; nor
        does it represent that it has made any independent effort to
        identify any such rights.  Information on the procedures with
        respect to rights in RFC documents can be found in BCP 78 and
        BCP 79.

        Copies of IPR disclosures made to the IETF Secretariat and any
        assurances of licenses to be made available, or the result of an
        attempt made to obtain a general license or permission for the
        use of such proprietary rights by implementers or users of this
        specification can be obtained from the IETF on-line IPR
        repository at http://www.ietf.org/ipr.

        The IETF invites any interested party to bring to its attention
        any copyrights, patents or patent applications, or other
        proprietary rights that may cover technology that may be


     Ould-Brahim, Fedyk, Rekhter   Expires July 2008            [Page 9]


Internet-Draft  BGP Auto-Discovery for L1VPNs          January 2008


        required to implement this standard.  Please address the
        information to the IETF at ietf-ipr@ietf.org.

        Copyright (C) The IETF Trust (2008).

        This document is subject to the rights, licenses and
        restrictions contained in BCP 78, and except as set forth
        therein, the authors retain all their rights.

        This document and the information contained herein are provided
        on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
        REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
        THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
        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.































     Ould-Brahim, Fedyk, Rekhter   Expires July 2008        [Page 10]