RFC5195 日本語訳

5195 BGP-Based Auto-Discovery for Layer-1 VPNs. H. Ould-Brahim, D.Fedyk, Y. Rekhter. June 2008. (Format: TXT=21480 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                     H. Ould-Brahim
Request for Comments: 5195                                      D. Fedyk
Category: Standards Track                                         Nortel
                                                              Y. Rekhter
                                                        Juniper Networks
                                                               June 2008

Network Working Group H. Ould-Brahim Request for Comments: 5195 D. Fedyk Category: Standards Track Nortel Y. Rekhter Juniper Networks June 2008

               BGP-Based Auto-Discovery for Layer-1 VPNs

BGP-Based Auto-Discovery for Layer-1 VPNs

Status of This Memo

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

Abstract

   The purpose of this document is to define a BGP-based auto-discovery
   mechanism for Layer-1 VPNs (L1VPNs).  The auto-discovery mechanism
   for L1VPNs allows the provider network devices to dynamically
   discover the set of Provider Edges (PEs) having ports attached to
   Customer Edge (CE) members of the same VPN.  That information is
   necessary for completing the signaling phase of L1VPN connections.
   One main objective of a L1VPN auto-discovery mechanism is to support
   the "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 purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "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

1. Introduction

   The purpose of this document is to define a BGP-based auto-discovery
   mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK].  The auto-discovery
   mechanism for L1VPNs allows the provider network devices to
   dynamically discover the set of PEs having ports attached to CE
   members of the same VPN.  That information is necessary for
   completing the signaling phase of L1VPN connections.  One main
   objective of a L1VPN auto-discovery mechanism is to support the
   "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 purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK]. The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of PEs having ports attached to CE members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "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.

Ould-Brahim, et al.         Standards Track                     [Page 1]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 1] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

   The auto-discovery mechanism proceeds by having a PE advertise to
   other PEs the following information, 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 the signaling phase of
   Layer-1 VPN connections.

The auto-discovery mechanism proceeds by having a PE advertise to other PEs the following information, 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 the signaling phase of Layer-1 VPN connections.

   Figure 1 highlights the network reference for using a BGP-based
   auto-discovery mechanism for Layer-1 VPNs.  For the purpose of the
   auto-discovery mechanism, BGP is running only on the provider
   network.  The PEs maintain per-VPN information tables called Port
   Information Tables (PITs) related to <private address, provider
   address> information.  More information on the PITs is in Section 2.

Figure 1 highlights the network reference for using a BGP-based auto-discovery mechanism for Layer-1 VPNs. For the purpose of the auto-discovery mechanism, BGP is running only on the provider network. The PEs maintain per-VPN information tables called Port Information Tables (PITs) related to <private address, provider address> information. More information on the PITs is in Section 2.

                   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  |
   +--------+  | |     | |             | |          | | +--------+
               | +-----+ |             | +----------+ |
               +---------+             +--------------+

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: BGP Auto-Discovery for L1VPN

Figure 1: BGP Auto-Discovery for L1VPN

   [L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic
   mode and the enhanced mode.  This document describes an auto-
   discovery mechanism for the basic mode only.

[L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic mode and the enhanced mode. This document describes an auto- discovery mechanism for the basic mode only.

1.1.  Requirements Language

1.1. Requirements Language

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

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

Ould-Brahim, et al.         Standards Track                     [Page 2]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 2] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

2.  Procedures

2. Procedures

   In the context of L1VPNs, a CE is connected to a PE via one or more
   ports, where each port may consist 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 L1VPNs).  We refer to this identifier as the customer
   port identifier (CPI).  Each port on a PE also has an identifier that
   is unique within the provider network.  We refer to this identifier
   as the provider port identifier (PPI).  Note that IP addresses used
   for CPIs or PPIs could be either IPv4 or IPv6 addresses.

In the context of L1VPNs, a CE is connected to a PE via one or more ports, where each port may consist 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 L1VPNs). We refer to this identifier as the customer port identifier (CPI). Each port on a PE also has an identifier that is unique within the provider network. We refer to this identifier as the provider port identifier (PPI). Note that IP addresses used for CPIs or PPIs could be either IPv4 or IPv6 addresses.

   For each L1VPN that has at least one port configured on a PE, the PE
   maintains a Port Information Table (PIT).  A PIT contains a list of
   <CPI, PPI> tuples for all the ports within its L1VPN.  Note that a
   PIT may also hold routing information (for example, when CPIs are
   learnt using a routing protocol).

For each L1VPN that has at least one port configured on a PE, the PE maintains a Port Information Table (PIT). A PIT contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. Note that a PIT may also hold routing information (for example, when CPIs are learnt using a routing protocol).

   A PIT on a given PE is populated with two types of information.

A PIT on a given PE is populated with two types of information.

   - Information related to the CEs' ports attached to the ports on the
     PE.  This information could be locally configured at the PE or
     could be received from the CEs.

- Information related to the CEs' ports attached to the ports on the PE. This information could be locally configured at the PE or could be received from the CEs.

   - Information received from other PEs through the auto-discovery
     mechanism.

- Information received from other PEs through the auto-discovery mechanism.

   We refer to the former as local information, and to the latter as
   remote information.  Propagation of local information to other PEs is
   accomplished by using BGP multiprotocol extensions [RFC4760].  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.

We refer to the former as local information, and to the latter as remote information. Propagation of local information to other PEs is accomplished by using BGP multiprotocol extensions [RFC4760]. 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 the 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 (at
   provisioning time) 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 one of these Communities.

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 the 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 (at provisioning time) 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 one of these Communities.

   Each of the following occurs at provisioning time: if a service
   provider adds a new L1VPN port to a particular PE, this port is
   associated with a PIT on that PE, and this PIT is associated with
   that L1VPN.

Each of the following occurs at provisioning time: if a service provider adds a new L1VPN port to a particular PE, this port is associated with a PIT on that PE, and this PIT is associated with that L1VPN.

Ould-Brahim, et al.         Standards Track                     [Page 3]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 3] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

   Note that since the protocol used to populate a PIT with remote
   information is BGP, and since BGP works across multiple autonomous
   systems (ASs), it follows that the mechanism described in this
   document could support L1VPNs that span multiple autonomous systems.

Note that since the protocol used to populate a PIT with remote information is BGP, and since BGP works across multiple autonomous systems (ASs), it follows that the mechanism described in this document could support L1VPNs that span multiple autonomous systems.

   Although multi-AS L1VPNs are currently out of scope for the Basic
   Mode, the mechanisms defined in this document appear to be easily
   applicable to a multi-AS scenario, should such a need arise in the
   future.  At that time, additional work may be required to examine
   various aspects including security.

Although multi-AS L1VPNs are currently out of scope for the Basic Mode, the mechanisms defined in this document appear to be easily applicable to a multi-AS scenario, should such a need arise in the future. At that time, additional work may be required to examine various aspects including security.

3.  Carrying L1VPN Information in BGP

3. Carrying L1VPN Information in BGP

   The <CPI, PPI> mapping is carried using the Multiprotocol Extensions
   to 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 subsequent address family identifier, called
   Layer-1 VPN auto-discovery information (value 69), and also a new
   Network Layer Reachability Information (NLRI) format for carrying the
   CPI and PPI information.

The <CPI, PPI> mapping is carried using the Multiprotocol Extensions to 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 subsequent address family identifier, called Layer-1 VPN auto-discovery information (value 69), and also a new Network Layer Reachability Information (NLRI) format for carrying the CPI and PPI information.

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

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

   The format of the NLRI is described in Figure 2.

The format of the NLRI is described in Figure 2.

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

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

                   |     Length (1 octet)                  |

| Length (1 octet) |

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

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

                   |     Auto-discovery info (variable)    |

| Auto-discovery info (variable) |

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

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

                         Figure 2: Encoding of the NLRI

Figure 2: Encoding of the NLRI

   Note that the encoding of the auto-discovery information is described
   in [L1VPN-BM], and note also that if the value of the Length of the
   Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next
   Hop contains an IPv4 address.  If this value is 16, then the Next Hop
   contains an IPv6 address.

Note that the encoding of the auto-discovery information is described in [L1VPN-BM], and note also that if the value of the Length of the Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address.

Ould-Brahim, et al.         Standards Track                     [Page 4]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 4] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

4.  Carrying L1VPN Traffic Engineering Information in BGP

4. Carrying L1VPN Traffic Engineering Information in BGP

   In addition to reachability information, the auto-discovery mechanism
   MAY carry Traffic Engineering information used for the purpose of
   egress path selection.  For example, a PE may learn the switching
   capability and the maximum LSP bandwidth of remote L1VPN interfaces
   from the remote PEs.  This document uses the BGP Traffic Engineering
   Attribute [BGP-TE-ATTRIBUTE] to carry such information.

In addition to reachability information, the auto-discovery mechanism MAY carry Traffic Engineering information used for the purpose of egress path selection. For example, a PE may learn the switching capability and the maximum LSP bandwidth of remote L1VPN interfaces from the remote PEs. This document uses the BGP Traffic Engineering Attribute [BGP-TE-ATTRIBUTE] to carry such information.

5.  Scalability

5. Scalability

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

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

   A PE router, unless it is a Route Reflector, does not retain L1VPN-
   related information unless it has at least one VPN with an import
   Route Target identical to one of the VPN-related information Route
   Target attributes.  If a PE does not have a VPN with a matching
   import Route Target, it MUST then discard received l1VPN information.
   Inbound filtering MUST be used to cause such information to be
   discarded.  If a new import Route Target is later added to one of the
   PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN-
   related information it previously has discarded.

A PE router, unless it is a Route Reflector, does not retain L1VPN- related information unless it has at least one VPN with an import Route Target identical to one of the VPN-related information Route Target attributes. If a PE does not have a VPN with a matching import Route Target, it MUST then discard received l1VPN information. Inbound filtering MUST be used to cause such information to be discarded. If a new import Route Target is later added to one of the PE's VPNs (a "VPN Join" operation), it MUST then acquire the VPN- related information it previously has discarded.

   In this case, the refresh mechanism described in [BGP-RFSH] MUST be
   used.  The outbound route filtering mechanisms of [BGP-ORF] and
   [BGP-CONS] can also be used to advantage to make the filtering more
   dynamic.

In this case, the refresh mechanism described in [BGP-RFSH] MUST be used. The outbound route filtering mechanisms of [BGP-ORF] and [BGP-CONS] can also be used to advantage to make the filtering more dynamic.

   Similarly, if a particular import Route 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 the L1VPN BGP routes that, as a
   result, no longer have any of the PE's PIT's import Route Targets as
   one of their Route Target attributes.

Similarly, if a particular import Route 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 the L1VPN BGP routes that, as a result, no longer have any of the PE's PIT's import Route Targets as one of their Route Target attributes.

   Note that "VPN Join" and "VPN 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.

Note that "VPN Join" and "VPN 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.

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.

Ould-Brahim, et al.         Standards Track                     [Page 5]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 5] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

   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.

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 External BGP (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.

For inter-provider VPNs, if multi-hop External BGP (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.

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.

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.

6.  Security Considerations

6. Security Considerations

   This document describes a BGP-based auto-discovery mechanism that
   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 that attach to the same VPN receive these BGP advertisements.
   This allows that set of PEs to discover each other.  Note that a PE
   will not always receive these advertisements directly from the remote
   PEs; the advertisements can be received from "intermediate" BGP
   speakers.

This document describes a BGP-based auto-discovery mechanism that 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 that attach to the same VPN receive these BGP advertisements. This allows that set of PEs to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements can be received from "intermediate" BGP speakers.

   It is of critical importance that a particular PE MUST 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 trust those peers to be properly securing their

It is of critical importance that a particular PE MUST 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 trust those peers to be properly securing their

Ould-Brahim, et al.         Standards Track                     [Page 6]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 6] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

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

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 [RFC2385] SHOULD 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 a BGP peer of the local PE, then the BGP authentication procedures of [RFC2385] SHOULD 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 MUST be used only in environments where adequate trust
   relationships exist among the BGP speakers (such as the case of using
   the auto-discovery mechanism within a single provider network).

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 MUST be used only in environments where adequate trust relationships exist among the BGP speakers (such as the case of using the auto-discovery mechanism within a single provider network).

7.  IANA Considerations

7. IANA Considerations

   This document assigns a new SAFI, called Layer-1 VPN auto-discovery
   information (see Section 3).  This assignment has been made in the
   Subsequent Address Family Identifier (SAFI) registry using the
   Standards Action allocation procedures.  The value is 69.

This document assigns a new SAFI, called Layer-1 VPN auto-discovery information (see Section 3). This assignment has been made in the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. The value is 69.

8.  References

8. References

8.1.  Normative References

8.1. Normative References

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

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

   [RFC4760]    Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
                "Multiprotocol Extensions for BGP-4", RFC 4760, January
                2007.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

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

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

8.2.  Informative References

8.2. Informative References

   [BGP-TE-ATTRIBUTE]
                Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic
                Engineering Attribute", Work in Progress, January 2008.

[BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., "Traffic Engineering Attribute", Work in Progress, January 2008.

Ould-Brahim, et al.         Standards Track                     [Page 7]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 7] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

   [BGP-ORF]    Chen, E. and Y. Rekhter, "Outbound Route Filtering
                Capability for BGP-4", Work in Progress, September 2006.

[BGP-ORF] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", Work in Progress, September 2006.

   [BGP-CONS]   Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
                R., Patel, K., and J. Guichard, "Constrained Route
                Distribution for Border Gateway Protocol/MultiProtocol
                Label Switching (BGP/MPLS) Internet Protocol (IP)
                Virtual Private Networks (VPNs)", RFC 4684, November
                2006.

[BGP-CONS] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.

   [BGP-COMM]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
                Communities Attribute", RFC 4360, February 2006.

[BGP-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

   [L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1
                Virtual Private Networks", RFC 4847, April 2007.

[L1VPN-FRMK] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.

   [L1VPN-BM]   Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
                Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode",
                Work in Progress, February 2008.

[L1VPN-BM] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Work in Progress, February 2008.

   [RFC2385]    Heffernan, A., "Protection of BGP Sessions via the TCP
                MD5 Signature Option", RFC 2385, August 1998.

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

9.  Acknowledgment

9. Acknowledgment

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

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

Ould-Brahim, et al.         Standards Track                     [Page 8]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 8] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

Authors' Addresses

Authors' Addresses

   Hamid Ould-Brahim
   Nortel
   PO Box 3511 Station C
   Ottawa ON K1Y 4H7
   Canada

Hamid Ould-Brahim Nortel PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada

   Phone: +1 (613) 763 4730
   EMail: hbrahim@nortel.com

Phone: +1 (613) 763 4730 EMail: hbrahim@nortel.com

   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089
   USA

Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA

   EMail: yakov@juniper.net

EMail: yakov@juniper.net

   Don Fedyk
   Nortel
   600 Technology Park
   Billerica, MA 01821
   USA

Don Fedyk Nortel 600 Technology Park Billerica, MA 01821 USA

   Phone: +1 (978) 288 3041
   Email: dwfedyk@nortel.com

Phone: +1 (978) 288 3041 Email: dwfedyk@nortel.com

Ould-Brahim, et al.         Standards Track                     [Page 9]

RFC 5195             BGP Auto-Discovery for L1VPNs             June 2008

Ould-Brahim, et al. Standards Track [Page 9] RFC 5195 BGP Auto-Discovery for L1VPNs June 2008

Full Copyright Statement

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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.

Intellectual Property

Intellectual Property

   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.

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.

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 required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

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 required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Ould-Brahim, et al.         Standards Track                    [Page 10]

Ould-Brahim, et al. Standards Track [Page 10]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Date.getUTCDay

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る