Internet DRAFT - draft-you-idr-bgp-vpn-discovery
draft-you-idr-bgp-vpn-discovery
Idr Working Group J. You
Internet-Draft Q. Liang
Intended status: Standards Track Huawei
Expires: March 19, 2015 September 15, 2014
BGP VPN Peer Discovery Method
draft-you-idr-bgp-vpn-discovery-00
Abstract
This document proposes a VPN peer discovery method based on BGP. All
BGP peers need to establish sessions with a centralized control point
which collects and distributes BGP VPN Peer information according to
local policies or filtering policies subscribed from BGP peers.
Thereafter, the BGP node can select the interested peers with the
same VPN services to establish sessions. This would avoid
unnecessary session between uninterested BGP peers.
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 19, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
You & Liang Expires March 19, 2015 [Page 1]
Internet-Draft BGP VPN Discovery September 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. VPN Peer Discovery Method . . . . . . . . . . . . . . . . . . 3
3.1. VPN Peer Filter . . . . . . . . . . . . . . . . . . . . . 3
3.2. VPN Peer Information . . . . . . . . . . . . . . . . . . 5
3.3. Deployment Considerations . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The base BGP-4 specification ([RFC4271]) utilizes TCP for session
establishment between peers, which requires prior knowledge of the
end point's address to which a BGP session should be targeted. The
BGP auto discovery [I-D.raszuk-idr-bgp-auto-discovery] describes a
method for automating portions of a router's BGP configuration via
discovery of BGP peers with which to establish further sessions from
an initial "bootstrap" router. However, in
[I-D.raszuk-idr-bgp-auto-discovery], the VPN information of BGP peers
is not collected by the "bootstrap" router. Instead, the VPN-related
information is obtained after the BGP session established between BGP
peers ([RFC4761], [RFC6624]). Basically, if there's no same VPN
service between the BGP nodes, there's no need to establish the BGP
session. If BGP node can obtain the VPN information of the BGP peers
before BGP session establishment, it could avoid unnecessary session
between uninterested BGP peers.
This document proposes a VPN peer discovery method based on BGP. All
BGP peers need to establish sessions with a centralized control point
which collects and distributes BGP VPN Peer information according to
local policies or filtering policies subscribed from BGP peers.
You & Liang Expires March 19, 2015 [Page 2]
Internet-Draft BGP VPN Discovery September 2014
Thereafter, the BGP node can select the interested peers with the
same VPN services to establish sessions. From OAM aspects, it is
beneficial for BGP node only following the interested BGP peers based
on its filtering policies e.g. BGP peers in a specified AS. So this
BGP node doesn't need to follow the VPN information of the BGP peers
in other ASs. Thus, the BGP session between uninterested BGP peers
will not be established.
2. Terminology
This section contains definitions for terms used frequently
throughout this document. However, many additional definitions can
be found in [RFC4760] and [RFC5575].
AFI: Address Family Identifier
AS: Autonomous System number
NLRI: Network Layer Reachability Information
RD: Route Distinguisher
RR: Route Reflector
SAFI: Subsequent Address Family Identifier
3. VPN Peer Discovery Method
The centralized control point collects all the VPN service
information of BGP nodes within the domain, and then distributes the
BGP VPN Peer information to the BGP peers according to local policies
or filtering policies subscribed from BGP peers.
3.1. VPN Peer Filter
A new Path Attribute, i.e. VPN Peer Filter Attribute (Type Code:
TBD1) is defined to carry VPN peer filtering information. It is
carried in the BGP Update message. This attribute is used by the BGP
peer for subscribing the interested VPN peer information towards the
centralized control point.
The format of VPN Peer Filter Attribute is defined in Figure 1:
You & Liang Expires March 19, 2015 [Page 3]
Internet-Draft BGP VPN Discovery September 2014
+-----------------------------------------------------+
|Attr. Flags (1 octet) | Attr. Typr Code (1 Octec) |
+-----------------------------------------------------+
| Attribute Length (2 octets) |
+-----------------------------------------------------+
| Filter 1 (var) |
+-----------------------------------------------------+
| ... |
+-----------------------------------------------------+
| Fitler N (var) |
+-----------------------------------------------------+
Figure 1: VPN Peer Filter Attribute
The attribute flags and type code fields are detailed in Figure 2:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+---------------+
|1|0|0|0|0|0|0|0| TBD1 |
+-+-+-+-+-+-+-+-+---------------+
Figure 2: Flags & Type Code Fields
Bit 0: Optional attribute (value 1)
Bit 1: Non transitive attribute (value 0)
Bit 2: Partial bit (value 0 for optional non transitive
attributes)
Bit 3: Length of one octet (value 0)
Bit 4-7: Unused (value all zeros)
Type code: Attribute type code TBD1
Each VPN Peer Filter Attribute contains one or more filters. The
Filter is encoded as: <type (1 octet), [op, value]+> ([RFC5575]). It
contains a set of {operator, value} pairs that are used to match the
specified value of the corresponding type defined in filter encoding.
The operator byte is encoded as:
You & Liang Expires March 19, 2015 [Page 4]
Internet-Draft BGP VPN Discovery September 2014
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a |not|eq |str| len |
+---+---+---+---+---+---+---+---+
Figure 3: Numeric Operator
e: end-of-list bit. Set in the last {op, value} pair in the list.
a: AND bit. If unset, the previous term is logically ORed with
the current one. If set, the operation is a logical AND. It
should be unset in the first operator byte of a sequence. The AND
operator has higher priority than OR for the purposes of
evaluating logical expressions.
not: NOT bit. If set, logical negation of operation.
eq: equality between data and value.
str: STRING bit. If set, the value is an ASCII string.
len: The length of the value field for this operand is given as (1
<< len).
For the filter, the following types are defined:
type 1 - RD: RD, 8 octets
type 2 - AS: AS, 4 octets
type 3 - AFI/SAFI: AFI/SAFI, 3 octets
type 4 - Service Type: Service Type, 2 octets, to identify a VPN
service type, e.g. EVPN, Kompella VPLS [RFC4761], BGP AD VPLS
[RFC6074], IP VPN.
type 5 - Peer IP: Peer IP, 4 octets for IPv4 or 16 octets for
IPv6.
type 6 - Export RT: RT/VPN target, 8 octets, filled with local
import RTs/VPN targets of the subscriber.
3.2. VPN Peer Information
The BGP Speaker can use the Network Layer Reachability Information
field of the MP_REACH_NLRI ([RFC4760]) attribute to notify the peer
the corresponding VPN peer information, which is satisfied with local
or peer's filtering policies. Similarly, The BGP Speaker can use the
You & Liang Expires March 19, 2015 [Page 5]
Internet-Draft BGP VPN Discovery September 2014
Withdrawn Route NLRIs field of the MP_UNREACH_NLRI ([RFC4760])
attribute to notify the peer of removing the corresponding VPN peer
information.
Besides, this document defines a new value for the Address Family
Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI
attributes:
3 (TBD2) - Network Layer Reachability Information used for VPN
Service
For the Subsequent Address Family Identifier field carried in the
MP_REACH_NLRI and MP_UNREACH_NLRI attributes, if AFI = 3 (TBD), then
the SAFI could be set to 0 by the sender, and it is ignored by the
receiver.
The Network Layer Reachability information is encoded as one or more
2-tuples of the form <length, prefix> ([RFC4760]).
The extended Network Layer Reachability information field of the
MP_REACH_NLRI or the Withdrawn Route NLRIs field of the
MP_UNREACH_NLRI is encoded as shown in Figure 4, therein the VPN
information including service type, RD, AS, AFI/SAFI and peer address
can be regarded as a particular prefix.
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Service Type (1 octet) |
+-----------------------------------+
| Route Distinguisher (8 octets) |
+-----------------------------------+
| AS (4 octets) |
+-----------------------------------+
| AFI/SAFI (3 octets) |
+-----------------------------------+
| Peer Address (4 or 16 octets) |
+-----------------------------------+
Figure 4: VPN Service Informatiom
The use and meaning of these fields are as follows:
Length: The Length field indicates the length of the VPN service
information, including service type, RD, AS, AFI/SAFI and peer
address.
You & Liang Expires March 19, 2015 [Page 6]
Internet-Draft BGP VPN Discovery September 2014
Service Type: Service type is used to identify a VPN service type,
e.g. EVPN, Kompella VPLS [RFC4761], BGP AD VPLS [RFC6074], IP
VPN.
Route Distinguisher (RD): An 8-byte Route Distinguisher
AS: Autonomous System number
Address Family Identifier (AFI): This field in combination with
the Subsequent Address Family Identifier field identifies the set
of Network Layer protocols to which the address carried in the
Next Hop field must belong, the way in which the address of the
next hop is encoded, and the semantics of the Network Layer
Reachability Information that follows. If the Next Hop is allowed
to be from more than one Network Layer protocol, the encoding of
the Next Hop MUST provide a way to determine its Network Layer
protocol. Presently defined values for the Address Family
Identifier field are specified in the IANA's Address Family
Numbers registry.
Subsequent Address Family Identifier (SAFI): This field in
combination with the Address Family Identifier field identifies
the set of Network Layer protocols to which the address carried in
the Next Hop must belong, the way in which the address of the next
hop is encoded, and the semantics of the Network Layer
Reachability Information that follows. If the Next Hop is allowed
to be from more than one Network Layer protocol, the encoding of
the Next Hop MUST provide a way to determine its Network Layer
protocol.
Peer Address: the address of the peer, 4 bytes for IPv4, and 16
bytes for IPv6.
3.3. Deployment Considerations
The centralized control point can be deployed on the RR. Then the RR
needs to establish the sessions with all the PEs to obtain the
interested VPN peer information.
BGP nodes use VPN Peer Filter Attribute (Type Code: TBD1) for
subscribing the interested VPN peer information towards the
centralized control point.
The RR notifies the BGP peer the corresponding VPN peer information
(an extended Network Layer Reachability Information), which is
satisfied with local or peer's filtering policies.
You & Liang Expires March 19, 2015 [Page 7]
Internet-Draft BGP VPN Discovery September 2014
4. IANA Considerations
This document defines a new Path Attribute, i.e. VPN Peer Filter
Attribute (Type Code: TBD1), which will be used to carry VPN peer
filtering information. A new attribute type code TBD1 is to be
assigned by IANA from the BGP path attribute Type Code space.
This document defines a new MP_REACH_NLRI /MP_UNREACH_NLRI AFI type
code TBD2 which will be used to carry VPN service. That value will
need to be assigned by IANA from BGP AFI Type Code space.
This document defines a new NLRI format, to be carried in
MP_REACH_NLRI and MP_UNREACH_NLRI attributes.
5. Security considerations
This extension to BGP does not change the underlying security issues
inherent in the existing BGP.
6. Acknowledgement
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009.
You & Liang Expires March 19, 2015 [Page 8]
Internet-Draft BGP VPN Discovery September 2014
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074, January
2011.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, May 2012.
7.2. Informative References
[I-D.raszuk-idr-bgp-auto-discovery]
Raszuk, R., Kumari, W., Mitchell, J., Patel, K., and J.
Scudder, "BGP Auto Discovery", draft-raszuk-idr-bgp-auto-
discovery-01 (work in progress), August 2014.
Authors' Addresses
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
Qiandeng Liang
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: liuweihang@huawei.com
You & Liang Expires March 19, 2015 [Page 9]
