One document matched: draft-xu-softwire-tunnel-endpoint-03.txt
Differences from draft-xu-softwire-tunnel-endpoint-02.txt
Network working group X. Xu
Internet Draft Huawei
Category: Standard Track P. Francis
MPI-SWS
Y. Cui
Tsinghua University
R. Raszuk
Cisco
Expires: September 2011 March 8, 2011
Simple Tunnel Endpoint Signaling in BGP
draft-xu-softwire-tunnel-endpoint-03
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 September 8, 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
Xu, et al. Expires September 8, 2011 [Page 1]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
carefully, as they describe your rights and restrictions with
respect to this document.
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 Extended Community, 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 Extended Community............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 September 8, 2011 [Page 2]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
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 September 8, 2011 [Page 3]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
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 Extended
Community, 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 September 8, 2011 [Page 4]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
In a scenario as shown in Figure 1, the Tunnel Endpoint Extended
Community 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 Extended Community 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 September 8, 2011 [Page 5]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
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
Extended Community associated with the E-IP routes MUST be removed
by the AFBR. For example, R12 MUST remove the Tunnel Endpoint
Extended Community 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 Extended Community 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 Extended Community
This document proposes a new IPv4 address specific extended
community attribute [RFC4360] and a new IPv6 address specific
extended community attribute [RFC5701] respectively to be used as
the Tunnel Endpoint Extended Community 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 Extended Community 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 Extended Community to
E-IP routes that enter the I-IP network domain.
b) All AFBRs MUST remove the Tunnel Endpoint Extended Community
associated to E-IP routes that enter the E-IP network domain.
Xu, et al. Expires September 8, 2011 [Page 6]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
c) If an AFBR selects a route associated with a Tunnel Endpoint
Extended Community as the best path, then the AFBR MUST tunnel
packets matching that route towards the tunnel endpoint address
associated with that route.
d) Non-AFBR ABSRs SHOULD NOT remove the Tunnel Endpoint Extended
Community from the route update.
e) When aggregating two or more specific routes with different
Tunnel Endpoint Extended Communities into an aggregated route,
the aggregating router MUST strip the original Tunnel Endpoint
Extended Communities, and attach its own Tunnel Endpoint
Extended Community 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 Extended Community 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.
Xu, et al. Expires September 8, 2011 [Page 7]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP March 2011
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", RFC5701, November 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.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Email: xuxh@huawei.com
Paul Francis
Max Planck Institute for Software Systems
Gottlieb-Daimler-Strasse
Kaiserslautern 67633
Germany
Email: francis@mpi-sws.org
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Email: yong@csnet1.cs.tsinghua.edu.cn
Robert Raszuk
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: raszuk@cisco.com
Xu, et al. Expires September 8, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 10:41:19 |