Internet DRAFT - draft-ni-l3vpn-bgp-ext-sd-co-lsp
draft-ni-l3vpn-bgp-ext-sd-co-lsp
Network Working Group H. Ni
Internet-Draft S. Zhuang
Intended status: Standards Track Z. Li
Expires: August 17, 2014 Huawei Technologies
February 13, 2014
BGP Extensions for Service-Driven Co-Routed MPLS Traffic Engineering LSP
draft-ni-l3vpn-bgp-ext-sd-co-lsp-01
Abstract
In some large scale L3VPN deployment scenarios like mobile backhaul
network, it is required that tunnels between two PEs could be setup
automatically driven by L3VPN service to reduce manual configuration
effort. Moreover the tunnels must be setup co-routed for the
goodness of performance monitoring and uniform protection behavior
for link failure on two directions. This is described in [I-D.li-
mpls-serv-driven-co-lsp-fmwk]. This document introduces a new BGP VT
route based on [I-D.ni-bgp-ext-l3vpn-pm]. The route is utilized by
on side PE to advertise Tunnel ID to other side PE, so inverse
direction co-routed LSPs can be setup based on path information of
member LSPs in the first tunnel.
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 RFC 2119 [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 August 17, 2014.
Ni, et al. Expires August 17, 2014 [Page 1]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. VT Tunnel-ID Signal Route Definition . . . . . . . . . . . . 3
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Active/Passive PE Selection . . . . . . . . . . . . . . . 6
4.2. VPN Membership Auto Discovery . . . . . . . . . . . . . . 6
4.3. Active PE Advertise VT Tunnel-ID Signal Route . . . . . . 6
4.4. Passive PE advertise Tunnel ID to Active PE . . . . . . . 7
4.5. VT Tunnel-ID Signal Route Application . . . . . . . . . . 7
5. VT Tunnel-ID Signal Route Selection Consideration . . . . . . 8
6. Deployment Consideration . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
In some large scale L3VPN deployment scenarios like mobile backhaul
network, it is required that LSPs between two PEs could be setup
automatically driven by L3VPN service to reduce manual configuration
effort and the LSPs must be setup co-routed for the goodness of
performance monitoring and uniform protection behavior under link
failure, which is in detail described in [I-D.li-mpls-serv-driven-
co-lsp-fmwk].
This document introduces a new BGP Tunnel-ID Signal Route under VT
SAFI([I-D.ni-bgp-ext-l3vpn-pm]). After VPN-membership discovered one
PE can use the route to proactively advertise one direction MPLS TE
Tunnel ID to remote PE, the latter can setup inverse direction co-
routed LSPs based on path information of member LSPs of the first
Ni, et al. Expires August 17, 2014 [Page 2]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
tunnel. For RSVP-TE type LSP, the path information could be got from
RRO naturally.
The extension is based on VT SAFI defined in [I-D.ni-l3vpn-ext-l3vpn-
pm].
Type 1(VT VPN Membership A-D Route) is utilized to support VPN-
membership auto-discovery between a pair of VRFs.
A new Type 3 VT Route, namely VT Tunnel-ID Signal Route, is defined
in this document.
2. Terminologies
This document uses the terminologies defined in [RFC3031], [RFC3209],
[RFC4026] and [I-D.ni-l3vpn-ext-l3vpn-pm].
ERT: Export Route Target
IRT: Import Route Target
LSP: Label Switched Path
LSR: Label Switching Router
MPLS: Multi Protocol Label Switching
PE: Provider Edge Router in BGP/MPLS VPN
RRO: Record Route Object
RSVP-TE: Traffic Engineering Extensions of RSVP
VT: VRF-to-VRF Tunnel
3. VT Tunnel-ID Signal Route Definition
VT Tunnel-ID Signal Route defined as Type 3 Route under BGP VT NLRI
+----------------------------------------------+
| Route Type (1 octet) |
+----------------------------------------------+
| Length (1 octet) |
+----------------------------------------------+
| Route Type Specific (Variable) |
+----------------------------------------------+
Figure 1 IPv4 VT-Family NLRI
Ni, et al. Expires August 17, 2014 [Page 3]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
a) Route Type: Type 3: indicates VT Tunnel-ID Signal Route
b) Length indicates Route Type Specific field's length in octets
c) Route Type specific contains VT Tunnel-ID Signal Route
information, encoded as following diagram.
+----------------------------------------------+
| Local VRF's RD (8 octets) |
+----------------------------------------------+
| Local Router's IP Address |
+----------------------------------------------+
| Remote VRF's RD (8 octets) |
+----------------------------------------------+
| Remote Router's IP Address |
+----------------------------------------------+
| Tunnel Type (1 octet) |
+----------------------------------------------+
| Flags (1 octet) |
+----------------------------------------------+
| Tunnel ID (variable) |
+----------------------------------------------+
Figure 2 VT VRF-to-VRF Tunnel-ID Signal Route Format
a) Local VRF's RD Route Distinguisher of one VRF on advertising PE
encoded as [RFC4364] definition.
b) Local Router's IP Address: Advertising PE's IPv4/IPv6 address.
c) Remote VRF's RD Route Distinguisher of one VRF on Receiving PE
encoded as [RFC4364] definition.
d) Remote Router's IP Address: Receiving PE's IPv4/IPv6 address.
e) Tunnel Type: Indicates type of tunnel
Type 0: RESERVED
Type 1: RSVP-TE Tunnel
Type other: To be defined later if necessary
f) Flags: 8-bits Flags
Ni, et al. Expires August 17, 2014 [Page 4]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| reserved |R|
+-+-+-+-+-+-+-+-+
Figure 3 Tunnel Flags Format
The high-order 7 bits are RESERVED and MUST be filled with ZERO, the
lowest R bit is defined to indicate Tunnel's direction:
0-Passive: indicate the tunnel is setup by Passive PE
1-Active: indicate the tunnel is setup by Active PE
g) Tunnel ID Tunnel Identifier defined according to specific Tunnel
type.
For RSVP-TE type tunnel defined in this document, Tunnel Identifier
is < tunnel end point address, Reserved, Tunnel ID, Extended Tunnel
ID> as carried in the RSVP-TE LSP's SESSION Object [RFC3209].
Following diagram describes RSVP-TE IPv4 Tunnel ID as example.
+----------------------------------------------------------+
| IPv4 tunnel end point address (4 octets) |
+----------------------------------------------------------+
| MUST be zero (2 octets) | Tunnel ID (2 octets) |
+----------------------------------------------------------+
| Extended Tunnel ID (4 octets) |
+----------------------------------------------------------+
Figure 4 RSVP-TE Tunnel Identifier Format
a) IPv4 tunnel end point address: 4 octets IPv4 address of Egress PE.
b) Tunnel ID: 2 octets Tunnel Identifier allocated by Ingress PE
which remains constant over the life of the RSVP-TE tunnel.
c) Extended Tunnel ID: 4 octets Extended Tunnel Identifier which also
remains constant over the life of the RSVP-TE Tunnel, MUST be filled
with ZERO or IPv4 Address of Ingress PE.
<Local VRF's RD, Local Router's IP Address, Remote VRF's RD, Remote
Router's IP Address> which indicates a pair of VRFs is defined as the
Prefix of VT Tunnel-ID Signal Route.
Ni, et al. Expires August 17, 2014 [Page 5]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
4. Operations
4.1. Active/Passive PE Selection
For a pair of PEs which are going to exchange VT Tunnel-ID Signal
Routes need to select Active PE/Passive PE first. The selection
SHOULD be done by two ways:
a) Locally decided by manually configuration. That is one PE is
configured as Active PE and other PE is configured as Passive PE.
b) Doing auto-selection in BGP's Capability Negotiation phase.
Router IDs of the two PEs are compared as unsigned integers, the PE
with larger Router ID value MUST be selected as Active PE and the PE
with smaller Router ID value is selected as Passive PE.
4.2. VPN Membership Auto Discovery
Following the detailed description in [I-D.ni-bgp-ext-l3vpn-pm], all
PEs firstly need to send VT VPN A-D Routes to do VPN membership
discovery.
4.3. Active PE Advertise VT Tunnel-ID Signal Route
Once found a pair of VRFs between Active PE and Passive PE belongs to
the same VPN, Active PE MUST initialize setup a RSVP-TE tunnel to
Passive PE for the pair of VRFs. Once Tunnel ID is allocated
locally, Active PE MUST advertise the RSVP TE tunnel info to Passive
PE by using VT Tunnel-ID Signal Route:
Local VRF's RD: MUST be filled with Route Distinguisher value of the
Local VRF.
Local Router's IP Address: MUST be filled with Active PE's IPv4/IPv6
Address.
Remote VRF's RD: MUST be filled with Route Distinguisher value of the
remote VRF on Passive PE which belongs to same L3VPN with Local VRF.
Remote Router's IP Address: MUST be filled with Passive PE's IPv4/
IPv6 Address.
Tunnel Type: MUST be filled with a valid Tunnel Type value, for
example filled with value <1> which indicates RSVP-TE Tunnel.
Flags: the high-order 7 bits MUST be filled with ZERO and "R" bit
flag MUST be filled with value <1> which indicates the tunnel is
initialized by Active PE.
Ni, et al. Expires August 17, 2014 [Page 6]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
Tunnel ID: <IP tunnel end point address> field MUST be filled with IP
address of Passive PE, <Tunnel ID> field MUST be filled with the
Tunnel Identifier value allocated by Active PE, <Extended Tunnel ID>
filed MUST be filled with ZERO or IP address of Active PE.
Note that if tunnel goes down, the responding VT Tunnel-ID Signal
Route Withdrawal message SHOULD NOT be sent out.
4.4. Passive PE advertise Tunnel ID to Active PE
After receiving VT Tunnel-ID Signal Route from Active PE, Passive PE
gets all LSP's path information under the Tunnel and setup inverse
direction RSVP-TE LSPs following same path.
Once Tunnel ID is allocated locally, the Tunnel ID information MUST
be advertised from Passive PE to Active PE through VT Tunnel-ID
Signal Route:
Local VRF's RD: MUST be filled with Route Distinguisher value of the
Local VRF on Passive PE.
Local Router's IP Address: MUST be filled with Passive PE's IPv4/IPv6
Address.
Remote VRF's RD: MUST be filled with Route Distinguisher value of the
remote VRF on Active PE which belongs to same L3VPN with Local VRF.
Remote Router's IP Address: MUST be filled with Active PE's IPv4/IPv6
Address.
Tunnel Type: MUST be filled with a valid Tunnel Type value, usually
the tunnel Type SHOULD be same with previous Tunnel Type setup by
Active PE.
Flags: Filled "R" Flag with value "0" which indicates the tunnel is
setup by Passive PE.
Tunnel ID: "IPv4 tunnel end point address" field MUST be filled with
IP address of Active PE, "Tunnel ID" field MUST be filled with the
Tunnel Identifier value allocated by Passive PE, "Extended Tunnel ID"
MUST be filled with ZERO or IP Address of Passive PE.
4.5. VT Tunnel-ID Signal Route Application
When Active PE and Passive PE learnt VT Tunnel-ID Signal Routes from
each other, both PEs need binding two uni-direction Tunnels together
for the L3VPN. It means L3VPN traffic is transit over the tunnels
and that if Active PE changes LSP in Active Tunnel, Passive PE MUST
Ni, et al. Expires August 17, 2014 [Page 7]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
detect it and manipulate the reverse direction LSP in Passive Tunnel
accordingly through RSVP protocol.
5. VT Tunnel-ID Signal Route Selection Consideration
VT Tunnel-ID Signal Route SHOULD follow the BGP best route selection
procedure described in [RFC4271].
VT Tunnel-ID Signal Route MUST be advertised ONLY to the Peer from
which the best VT VPN A-D route is received. VT VPN A-D route is the
one which carries the same Remote VRF's RD value and Remote PE's IP
address.
If Peer receives VT Tunnel-ID Signal Route originated from itself,
the route MUST be ignored.
6. Deployment Consideration
This document currently supports deploying VT Tunnel-ID Signal Route
in 2 manners:
Inner-AS L3VPN: with Full-mesh IBGP sessions or Router Reflectors.
Inter-AS L3VPN: with Option A (VRF-to-VRF)[RFC4364].
How to support Inter-AS L3VPN Option B(MP-EBGP) [RFC4364] and
Option-C (Multi-Hop MP-EBGP) [RFC4364] will be described in this
draft's future version.
7. Security Considerations
This extension to BGP does not change the underlying security issues.
8. IANA Considerations
A new SAFI value to present VT Subsequent Address Family is required
and to be allocated by IANA.
9. Normative References
[I-D.li-mpls-serv-driven-co-lsp-fmwk]
Li, Z. and J. Dong, "A Framework for Service-Driven Co-
Routed MPLS Traffic Engineering LSPs", draft-li-mpls-serv-
driven-co-lsp-fmwk-02 (work in progress), January 2014.
Ni, et al. Expires August 17, 2014 [Page 8]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
[I-D.ni-l3vpn-pm-bgp-ext]
Ni, H., Zhuang, S., and Z. Li, "BGP Extension For L3VPN
Performance Monitoring", draft-ni-l3vpn-pm-bgp-ext-00
(work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
Authors' Addresses
Hui Ni
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: nihui@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Ni, et al. Expires August 17, 2014 [Page 9]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Ni, et al. Expires August 17, 2014 [Page 10]
