Internet DRAFT - draft-ni-bgp-ext-sd-co-lsp
draft-ni-bgp-ext-sd-co-lsp
Network Working Group Hui Ni
Internet Draft ShunWan Zhuang
Intended status: Standards Track Zhenbin Li
Expires: January 2014 Huawei
July 8, 2013
BGP Extensions for Service-Driven Co-Routed MPLS Traffic Engineering
LSP
draft-ni-bgp-ext-sd-co-lsp-00.txt
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), 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
This Internet-Draft will expire on January 8,2014.
Copyright Notice
Copyright (c) 2013 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
<ni> Expires January 8, 2014 [Page 1]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
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.
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.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 3
3. Terminologies ............................................... 3
4. VT Tunnel-ID Signal Route Definition ........................ 4
5. Operations .................................................. 6
5.1. Active/Passive PE Selection............................. 6
5.2. VPN Membership Auto Discovery........................... 7
5.3. Active PE Advertise VT Tunnel-ID Signal Route .......... 7
5.4. Passive PE advertise Tunnel ID to Active PE ............ 7
5.5. VT Tunnel-ID Signal Route Application .................. 8
6. VT Tunnel-ID Signal Route Selection Consideration ........... 8
7. Deployment Consideration..................................... 9
8. Security Considerations...................................... 9
9. Normative References......................................... 9
10. Informative References..................................... 10
11. Acknowledgments ........................................... 10
Ni Expires January 8, 2014 [Page 2]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
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 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-bgp-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. Conventions used in this document
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].
3. Terminologies
This document uses the terminologies defined in [RFC3031], [RFC3209],
[RFC4026] and [I-D.ni-bgp-ext-l3vpn-pm].
ERT: Export Route Target
IRT: Import Route Target
LSP: Label Switched Path
LSR: Label Switching Router
Ni Expires January 8, 2014 [Page 3]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
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
4. 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
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 |
+----------------------------------------------+
Ni Expires January 8, 2014 [Page 4]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
| 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
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.
Ni Expires January 8, 2014 [Page 5]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
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.
5. Operations
5.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.
Ni Expires January 8, 2014 [Page 6]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
5.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.
5.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.
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.
5.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.
Ni Expires January 8, 2014 [Page 7]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
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.
5.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
detect it and manipulate the reverse direction LSP in Passive Tunnel
accordingly through RSVP protocol.
6. 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
Ni Expires January 8, 2014 [Page 8]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
If Peer receives VT Tunnel-ID Signal Route originated from itself,
the route MUST be ignored.
7. 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.
8. Security Considerations
This extension to BGP does not change the underlying security issues.
9. Normative References
[1] [I-D.li-mpls-serv-driven-co-lsp-fmwk] Z. Li, "A
Framework for Service-Driven Co-Routed MPLS Traffic
Engineering LSPs", April 2013.
[2] [I-D.ni-bgp-ext-l3vpn-pm] H. Ni, "BGP Extension For
L3VPN Performance Monitoring", June 2013.
[3] [RFC3209] D. Awduche, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[4] [RFC4026] L. Andersson, "Provider Provisioned Virtual Private
Network (VPN) Terminology", RFC4026, March 2005.
[5] [RFC4271] Y. Rekhter, "A Border Gateway Protocol 4 (BGP-4)",
RFC 4271, January 2006.
[6] [RFC4364] E. Rosen, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[7] [RFC4456] T. Bates, "BGP Route Reflection: An Alternative to
Full Mesh Internal BGP (IBGP)", BCP 14, RFC 4456, April 2006.
Ni Expires January 8, 2014 [Page 9]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
10. Informative References
N.A
11. Acknowledgments
Ni Expires January 8, 2014 [Page 10]
Internet-Draft BGP Extension for Carry LSP ID In L3VPN July 2013
Authors' Addresses
Hui Ni
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: nihui@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Ni Expires January 8, 2014 [Page 11]
