Network working group X. Xu
Internet Draft Huawei
Category: Standard Track P. Francis
Expires: February 2011 MPI-SWS
Y. Cui
Tsinghua University
August 24, 2010
Simple Tunnel Endpoint Signaling in BGP
draft-xu-softwire-tunnel-endpoint-02
Status of this Memo
This Internet-Draft is submitted to IETF 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 February 24, 2011.
Copyright Notice
Copyright (c) 2010 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.
Xu, et al. Expires February 24, 2011 [Page 1]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
Abstract
The Softwire Mesh Framework provides a solution for intra-Autonomous
System (AS) softwire, but not inter-AS softwire. The ability to
provide inter-AS softwire extends the benefits of softwire to a
larger scale. Indeed, the above Framework discusses the possibility
of inter-AS softwire, but does not provide a solution. This document
defines a specific BGP Extended Community attribute called the
Tunnel Endpoint attribute, which allows for inter-AS softwire.
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].
Table of Contents
1. Terminology.................................................3
2. Problem Statement...........................................3
3. Inter-AS Softwire Mesh Solution.............................4
4. Syntax of the Tunnel Endpoint Attribute.....................6
5. Summary of Inter-AS Softwire Rules..........................6
6. Security Considerations.....................................7
7. IANA Considerations.........................................7
8. Acknowledgments.............................................7
9. References..................................................7
Authors' Addresses.............................................8
Xu, et al. Expires February 24, 2011 [Page 2]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
1. Terminology
This document uses the terms defined in [RFC2663] e.g., "I-IP"
(Internal IP), "E-IP" (External IP) and ''AFBR'' (Address Family
Border Router). Below are terms specific to this document:
- Non-AFBR ASBR: a special AFBR which only needs to operate E-IP
control plane, but not E-IP date-plane. That's to say, on the
control plane, the non-AFBR ASBR MUST be dual-stack and support
extended MP-BGP for softwire signalling, on the data plane, it only
supports I-IP address family.
2. Problem Statement
The Softwire Mesh Framework [RFC5565] mainly discusses softwire mesh
solution for intra-AS scenario, where a "transit core" consists of a
single Autonomous System (AS). The ability to provide inter-AS
softwire extends the benefits of intra-AS softwire, namely that I-IP
P routers do not need to operate the E-IP protocol (routing and
forwarding), to a larger scale. For example, an operator who owns
multiple ASes could form Inter-AS softwire mesh in its network.
In the Softwire Mesh Framework [RFC5565], three options are
suggested to deal with the inter-AS scenario:
a) Don't do it; require AFBRs to be deployed at the edge of each AS
so that a transit core does not extend to more than one AS.
b) Use multi-hop eBGP to allow AFBRs to send BGP routes to each
other, even if the ABFRs are not in the same or in neighboring
ASes.
c) Ensure that an Autonomous System Border Router (ASBR) that is
not an AFBR does not change the next-hop field of the routes for
which encapsulation is needed.
In option a, forwarding performance is reduced due to the extra
tunneling/detunneling operations on each AS edges.
In option b, AFBRs would have to afford to have the number of BGP
neighbors implied by inter-AS full mesh. Hence it is not scalable.
In option c, all those non-AFBR ASBRs would have to be upgraded to
support this particular capability. Besides, this option is a
substantial departure from the existing BGP control plane. Since BGP
Xu, et al. Expires February 24, 2011 [Page 3]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
requires that the IGP have routes to all possible BGP next-hops,
this approach increases the load on the IGP in unpredictable ways,
and weakens the separation between IGP and BGP.
3. Inter-AS Softwire Mesh Solution
This document suggests an alternative approach for inter-AS softwire
mesh which follows the "spirit" of approach 3 that tunneling
operations are not required on every AS edge. However, it uses a new
extended community attribute called Tunnel Endpoint Attribute, to
carry the tunnel endpoint address (i.e., I-IP address of the AFBR).
In contrast to approach 3, this approach fits much better into
current BGP operation because it doesn't change the semantics of the
BGP next-hop field. Besides, there is no need to upgrade non-AFBR
ASBRs in the middle ASes since the extended communities attribute is
a transitive optional BGP attribute.
+-----------------+
+-------+ | AS1(IPv4-only) |
| IPv6 | +------+ |
|Client |----| AFBR | |
|Network| |IPv4/6| |
+-------+ +------+ +--------+ |
CN1 R11 | |Non-AFBR| |
+---| ASBR |----+
+--------+ R12
|
+--------+R21
+---|Non-AFBR|----+
| | ASBR | |
| +--------+ |
| AS2(IPv4-only) |
| +--------+ |
| |Non-AFBR| |
+---| ASBR |----+
+--------+ R22
|
+--------+ R31
+---|Non-AFBR|----+
CN2 | | ASBR | |
+-------+ +------+ +--------+ |
| IPv6 | | AFBR | |
|Client |----|IPv4/6| |
|Network| +------+ |
+-------+ R32 | AS3(IPv4-only) |
+-----------------+
Figure 1: Inter-AS Softwire Scenario
Xu, et al. Expires February 24, 2011 [Page 4]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
In a scenario as shown in Figure 1, the Tunnel Endpoint Attribute
works as follows: AFBR R11 for instance would advertise an IPv6
prefix for Client Network CN1 in a BGP update, and attach a Tunnel
Endpoint Attribute conveying its own IPv4 address to the update.
This attribute would be carried along BGP until it reaches AFBR R32.
AFBR R32 would then learn to forward IPv6 packets destined for CN1
to AFBR R11 using an IPv4 tunnel.
Given that the non-AFBR ASBRs never actually forward IPv6 packets,
it is entirely possible to FIB-suppress the IPv6 prefixes so as to
isolate FIB size from the routing table growth in IPv6. It could
also be done for instance by implementing IPv6 forwarding capability
in software only, or by having no IPv6 forwarding capability at all.
This mode of operation reduces the hardware costs of those non-AFBR
ASBRs since they do not need to accommodate high-performance IPv6
forwarding in hardware, or accommodate IPv6 forwarding at all.
+-----------------+
+-------+ | AS1(IPv4-only) |
| IPv6 | +------+ |
|Client +----+ AFBR | |
|Network| |IPv4/6| |
+-------+ +------+ +------+ |
CN1 R11 | | AFBR | |
+----|IPv4/6|-----+
+------+ R12
|
+----+ R21
+-----|IPv6|------+
| +----+ |
| |
| AS2(IPv6-only) |
| |
| +----+ |
+-----|IPv6|------+
+----+ R22
|
+------+ R31
+----| AFBR |-----+
CN2 | |IPv4/6| |
+-------+ +------+ +------+ |
| IPv6 | | AFBR | |
|Client |----|IPv4/6| |
|Network| +------+ |
+-------+ R32 | AS3(IPv4-only) |
+-----------------+
Figure 2: Transit Core Containing E-IP ASes
Xu, et al. Expires February 24, 2011 [Page 5]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
In some special scenario where the transit core contains some E-IP
AS domains, as shown in Figure 2, to avoid stacked tunneling, once
the E-IP route enters an E-IP AS domain, the Tunnel Endpoint
Attribute associated with the E-IP routes MUST be removed by the
AFBR. For example, R12 MUST remove the Tunnel Endpoint Attribute
from the E-IP routes for CN1 before advertising them to R21 through
E-IP BGP sessions.
When multiple specific routes with different tunnel endpoint
addresses are aggregated, the aggregating router MUST attach a
Tunnel Endpoint Attribute with its own address as the tunnel
endpoint to the aggregated route. Note that the aggregating router
MUST be an AFBR because it advertises itself as the tunnel endpoint.
Where the tunnel type and/or additional tunnel parameters (i.e. for
GRE or L2TP) MUST be signaled, the mechanisms defined in [RFC5512]
could be used to signal these parameters. The two approaches for
tunnel signaling including the Tunnel Encapsulation Attribute and
the BGP Encapsulation Extended Community work well in inter-AS
scenario since these two attributes are transitive across ASes.
4. Syntax of the Tunnel Endpoint Attribute
This document proposes a new IPv4 address specific extended
community attribute [RFC4360] and a new IPv6 address specific
extended community attribute [I-D.ietf-l3vpn-v6-ext-communities]
respectively to be used as the Tunnel Endpoint Attribute for IPv6-
over-IPv4 scenario and IPv4-over-IPv6 scenario respectively. The
value of the high-order octet for the IPv4 type field is 0x01 and
for the IPv6 type field it is 0x00 since the Tunnel Endpoint
Attribute MUST be transitive across ASes. The value of the low-order
octet for the type field (i.e. the Sub-Type) is (TBD by IANA) for
IPv4 and (TBD by IANA) for IPv6. The Global Administrator field is
set to the Tunnel Endpoint address (i.e., one of the egress AFBR's
I-IP addresses which are routable in the transit network). The Local
Administrator field is set to zero and ignored upon receipt.
5. Summary of Inter-AS Softwire Rules
a) All AFBRs MUST attach the Tunnel Endpoint Attribute to E-IP
routes that enter the I-IP network domain.
b) All AFBRs MUST remove the Tunnel Endpoint Attribute associated
to E-IP routes that enter the E-IP network domain.
c) If an AFBR selects a route associated with a Tunnel Endpoint
Attribute as the best path, then the AFBR MUST tunnel packets
Xu, et al. Expires February 24, 2011 [Page 6]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
matching that route towards the tunnel endpoint address
associated with that route.
d) Non-AFBR ABSRs SHOULD NOT remove the Tunnel Endpoint Attribute
from the route update.
e) When aggregating two or more specific routes with different
Tunnel Endpoint Attributes into an aggregated route, the
aggregating router MUST strip the original Tunnel Endpoint
Attributes, and attach its own Tunnel Endpoint Attribute to the
aggregated route.
6. Security Considerations
If an AFBR chooses to disregard the I-IP tunnel route when selecting
the E-IP route, then the AS path taken by a packet may be different
from the AS path used to select the route. This, however, SHOULD
rarely if ever result in a security violation per se. It would
require that for some reason the security policy for selecting I-IP
paths and E-IP paths to be different and incompatible. An AS can
avoid this security issue either by having compatible security
policies for both E-IP and I-IP routes, or by taking into account
the I-IP tunnel route when selecting the E-IP route.
The mechanisms described in the security considerations of the
Softwire Mesh Framework [RFC5565] apply to the inter-domain softwire
described here.
7. IANA Considerations
A new Sub-Type of the Address Specific BGP Extended Communities
Attribute of IPv4 and IPv6 respectively SHOULD be issued by IANA for
the Tunnel Endpoint Attribute as described in Section 2.
8. Acknowledgments
The authors would like to thank Eric Rosen, Spencer Dawkins and Yiu
Lee for their valuable comments.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
Xu, et al. Expires February 24, 2011 [Page 7]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
[I-D.ietf-l3vpn-v6-ext-communities] Rekhter, Y., "IPv6 Address
Specific BGP Extended Communities Attribute",
draft-ietf-l3vpn-v6-ext-communities-02 (work in progress),
March 2009.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the
BGP Tunnel Encapsulation Attribute", RFC 5512, April
2009.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[I-D.draft-xu-tunnel] Xu, X., and Francis, P, "Simple Tunnel
Endpoint Signaling in BGP ", draft-xu-tunnel-00.txt (work
in progress), February 2009.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Paul Francis
Max Planck Institute for Software Systems
Gottlieb-Daimler-Strasse
Kaiserslautern 67633
Germany
Phone: +49 631 930 39600
Email: francis@mpi-sws.org
Yong Cui
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: yong@csnet1.cs.tsinghua.edu.cn
Xu, et al. Expires February 24, 2011 [Page 8]