One document matched: draft-xu-softwire-tunnel-endpoint-00.txt
Network working group X. XU
Internet Draft Huawei
Category: Standard Track P. Francis
Expires: April 2010 MPI-SWS
Y. Cui
Tsinghua University
October 19, 2009
Simple Tunnel Endpoint Signaling in BGP
draft-xu-softwire-tunnel-endpoint-00
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 April 19, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Xu, et al. Expires April 19, 2010 [Page 1]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
Abstract
The Softwire Mesh Framework [RFC5565] provides a solution for intra-
AS softwires, but not inter-AS softwires. The ability to provide
inter-AS softwires extends the benefits of softwires to a larger
scale. Indeed, [RFC5565] discusses the possibility of inter-AS
softwires, but does not provide a solution. This document defines a
specific Extended Community attribute called the Tunnel Endpoint
attribute, which allows for inter-AS softwires.
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. Introduction.................................................3
2. Syntax of the Tunnel Endpoint Attribute......................7
3. Usage of the Tunnel Endpoint Attribute.......................7
3.1. Cooperate with other BGP extensions for softwire........7
3.2. Inter-AS and Intra-AS mixed scenario....................8
3.3. Aggregation consideration..............................10
3.4. Summary of Inter-AS softwires rules....................12
4. Security Considerations.....................................12
5. IANA Considerations.........................................13
6. Acknowledgments.............................................13
7. Document Changes............................................13
7.1. Changes from draft-xu-idr-tunnel-00.txt................13
7.2. Changes from draft-xu-tunnel-00.txt....................13
8. References..................................................14
8.1. Normative References...................................14
8.2. Informative References.................................14
Authors' Addresses.............................................14
Xu, et al. Expires April 19, 2010 [Page 2]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
1. Introduction
This document uses the terms "I-IP" (Internal IP) and "E-IP"
(External IP) as they are used in [RFC5565]. The I-IP is the
internally used IP (i.e. IPv4 in Figure 2 and Figure 3), and the E-
IP is the externally supported IP (i.e. IPv6 in Figure 2 and Figure
3).
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 inter-AS deployment scenario is
mentioned as well, but no solution is provided. The benefits of
intra-AS softwires, namely that I-IP P routers do not need to
operate the E-IP protocol (routing and forwarding), applies to the
inter-AS case as well. In the context of the RFC5565 problem,
consider the following scenario (Figure 1):
+-----------------+
+-------+ | |
| IPv6 | +------+ IPv4 |
|Client |----| AFBR | only |
|Network| |IPv4/6| |
+-------+ +------+ +------+ |
| | AFBR | |
+----|IPv4/6|-----+
+------+
|
|
+------+
+----| AFBR |-----+
| |IPv4/6| |
+-------+ +------+ +------+ |
| IPv6 | | AFBR | |
|Client |----|IPv4/6| IPv4 |
|Network| +------+ only |
+-------+ | |
+-----------------+
Figure 1: Softwires mesh scenario of multiple transit Ases
Here, the packet from one IPv6 client network is tunneled over IPv4
in the first transit from the ingress AFBR to the egress AFBR. The
packet is de-tunneled at the egress AFBR, and then re-tunneled by
Xu, et al. Expires April 19, 2010 [Page 3]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
the next AFBR, i.e., the ingress AFBR of the second transit. If the
IPv4 tunnel could extend its end point and last from the ingress
AFBR of the first transit to the egress AFBR of the second transit
(Figure 2), the de-tunneling and re-tunneling in the middle could be
avoided. In fact, the two routers connecting the two transits (R52
and R61) need not have AFBR tunneling capabilities at all (though
they must still have extended MP-BGP capability to transmit E-IP
routes and tunnel signaling parameters, we'll refer to it as MP-BGP
control plane in this draft).
+-----------------+
+-------+ | AS5 |
| IPv6 | +------+ IPv4 |
|Client |----| AFBR | only |
|Network| |IPv4/6| |
+-------+ +------+ |
CN3 R51 | +------+ |
+----| IPv4 |-----+
+------+R52
|
|
+------+R61
+----| IPv4 |-----+
CN4 | +------+ |
+-------+ +------+ |
| IPv6 | | AFBR | |
|Client |----|IPv4/6| IPv4 |
|Network| +------+ only |
+-------+ R62 | AS6 |
+-----------------+
Figure 2: Tunnel Endpoint softwires scenario 1 (data plane only:
all border routers still require MP-BGP control planes). Note that
this could also be an IPv6 transit supporting IPv4 client networks.
Now consider the scenario of Figure 3 below. Here, there is a
transit network between two AFBR-capable transits that does not
operate any AFBR. RFC5565 points out the critical difference
between intra-AS and inter-AS scenario like Figure 3. For inter-AS
softwire, the AFBR at the remote endpoint of a softwire is not the
BGP next hop for packets that need to be sent on the softwire. Since
the intra-AS softwire solution require the remote softwire endpoint
address to be the same as the BGP next hop, it does not fit the
inter-AS situation.
Xu, et al. Expires April 19, 2010 [Page 4]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
+-----------------+
+-------+ | AS1 |
| IPv6 | +------+ IPv4 |
|Client |----| AFBR | only |
|Network| |IPv4/6| |
+-------+ +------+ |
CN1 R11 | +------+ |
+----| IPv4 |-----+
+------+ R12
|
+----+ R21
+-----|IPv4|------+
| +----+ |
| |
| AS2 |
| |
| +----+ |
+-----|IPv4|------+
+----+ R22
|
+------+ R31
+----| IPv4 |-----+
CN2 | +------+ |
+-------+ +------+ |
| IPv6 | | AFBR | |
|Client |----|IPv4/6| IPv4 |
|Network| +------+ only |
+-------+ R32 | AS3 |
+-----------------+
Figure 3: Tunnel Endpoint softwires scenario 2 (data plane only: all
border routers still require MP-BGP control planes). Note that
these could also be IPv6 transits supporting IPv4 client networks.
RFC5565 suggests three ways to deal with inter-AS scenarios:
1. 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.
2. 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.
Xu, et al. Expires April 19, 2010 [Page 5]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
3. Ensure that an ASBR that is not an AFBR does not change the
next hop field of the routes for which encapsulation is needed.
This first approach results in reduced forwarding performance for
many routers. This is both because of the extra tunneling
operations, and because IPv6 forwarding is slower than IPv4
forwarding (for IPv6-over-IPv4 scenario). What's more, it does not
apply to the scenario in Figure 3.
The second approach is not scalable: routers cannot afford to have
the number of BGP neighbors implied by inter-AS full mesh.
The third approach is a substantial departure from the existing BGP
control plane. In fact, since BGP requires that the IGP have routes
to all possible Next Hops, this approach increases the load on the
IGP in unpredictable ways, and weakens the separation between IGP
and BGP.
By contrast, the vast majority of routers today have both IPv4 and
IPv6 (MP-BGP) control planes even if they do not have AFBR
functionality. This suggests that a solution that exploits this
existing functionality is preferred to the three approaches of
RFC5565.
This draft suggests such a fourth approach. It follows the "spirit"
of approach 3 in which it does not require tunneling operations on
every AS edge. However, this approach fits much better into current
BGP operation. Namely, this draft proposes the Tunnel Endpoint
attribute: an attribute that carries the address of the tunnel
endpoint and is transitive across ASes.
In the context of Figure 3, the Tunnel Endpoint Attribute works as
follows. Note that the labels of the routers in Figure 3 refer only
to the data plane operation. The control plane of all border
routers must be dual-stack and support extended MP-BGP for softwire
(non-border routers can be IPv4 or IPv6 only). 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. This attribute would be carried along BGP until it
reaches AFBR R32. AFBR R32 would then learn to tunnel IPv6 packets
destined for CN1 to AFBR R11 using an IPv4 tunnel.
Given that the "IPv4" border routers never actually forward IPv6
packets, however, it is entirely possible to upgrade them to operate
with a "crippled" IPv6 data plane. This could be done by FIB-
suppressing the IPv6 prefixes, thus isolating FIB size from growth
in IPv6. It could also be done for instance by implementing IPv6
Xu, et al. Expires April 19, 2010 [Page 6]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
forwarding in software only, or by having no IPv6 forwarding
capability at all. This mode of operation reduces the hardware
costs of "IPv4" border routers, since they do not need to
accommodate high-performance IPv6 forwarding in hardware, or
accommodate IPv6 forwarding at all. (Or vice versa: the transit
networks could be IPv6 networks with crippled IPv4 data planes
interconnecting IPv4 client networks.)
2. Syntax of the Tunnel Endpoint Attribute
This draft describes a mechanism for advertising the tunnel endpoint
address across ASes in BGP. This draft uses both the Address
Specific BGP Extended Communities Attribute for IPv4 and IPv6
([RFC4360] and [I-D.ietf-l3vpn-v6-ext-communities]) to carry the
tunnel endpoint address respectively. Where the tunnel type and/or
additional tunnel parameters (i.e. for GRE or L2TP) must be signaled,
this draft uses the mechanisms (e.g., Tunnel Encapsulation Attribute
(TEncap-Attribute)) defined in [RFC5512] to encode these parameters.
A new IPv4 or IPv6 Address Specific BGP Extended Communities
Attribute is used as the Tunnel Endpoint Attribute. The value of the
high-order octet for the IPv4 type field is 0x01 as defined in
[RFC4360] and for the IPv6 type field it is 0x00 as defined in [I-
D.ietf-l3vpn-v6-ext-communities]. 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. The
attribute is transitive across ASes.
3. Usage of the Tunnel Endpoint Attribute
3.1. Cooperate with other BGP extensions for softwire
Since the existing BGP extensions for softwire (RFC4798, RFC5549,
RFC5512) are all defined under the scope of RFC5565, or we say,
these extensions are mainly well-considered for the intra-AS
scenario, it's necessary that we verify them for inter-AS scenario,
to see that if they works as well, with the Tunnel Endpoint
Attribute.
The extensions for softwire routing E-IP prefix in I-IP network are
defined in RFC4798 and RFC5549, for IPv6-over-IPv4 scenario and
IPv4-over-IPv6 scenario respectively. In both extensions, routes are
carried in MP_REACH_NLRI and MP_UNREACH_NLRI attributes. Since the
two attributes are non-transitive as defined, the non-AFBR border
Xu, et al. Expires April 19, 2010 [Page 7]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
BGP routers (e.g. routers labeled "IPv4" in Figure 3) must support
these MP-BGP extensions, or the routes will just be dropped with
MP_REACH_NLRI or MP_UNREACH_NLRI attributes. The corresponding
capability advertisement procedure is needed, as described in
RFC4798 and RFC5549.
RFC5512 provide two approaches to do tunnel signaling. The first one
is to use Tunnel Encapsulation Attribute. Tunnel Encapsulation
Attribute is already defined as a transitive attribute so as to be
passed through the intermediate BGP routers. The second approach is
to use BGP Encapsulation Extended Community (for the situation where
only tunnel type rather than along with other encapsulation
information is required). This extended community is transitive as
Tunnel Endpoint Attribute, so it works well in inter-AS scenario.
3.2. Inter-AS and Intra-AS mixed scenario
The approach using Tunnel Endpoint Attribute works well in the
complicated scenario where both inter-AS softwire and intra-AS
softwire exist. Figure 4 shows a typical example of this situation.
There is a collection of ASes and two client networks CN8 and CN9 in
this example. The client networks operate only the E-IP. There are
three ASes that operate as an inter-AS softwire "cloud": S-AS1, S-
AS2, and S-AS3 (S-AS means Softwire-AS, that is an AS which supports
softwire functionality by using AFBRs or ASBRs that support MP-BGP
for E-IP). In addition, there is a dual stack AS which is running
full dual-stack services (both control and data planes). The dual-
stack AS, however, is by agreement not considered part of the
softwires cloud. There is an AS that operates only the I-IP: it
offers no E-IP services at all (either data plane or control plane).
Finally, there is an AS that operates only the E-IP: it offers no
I-IP services at all.
Xu, et al. Expires April 19, 2010 [Page 8]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
+-------------------------------------------+
| S-AS1 |
+-------+ +----+R11 |
|Client |----|AFBR| |
|Network| +----+ |
+-------+ | |
CN8 | R12 R13 R14 R15 |
| +----+ +----+ +----+ +----+ |
+-|I-IP|------|AFBR|------|I-IP|-----|AFBR|-+
+----+ +----+ +----+ +----+
| | | |
| | | |
+--------+ +--------+ +-------+ +-------+
| S-AS2 | |Dual | |I-IP | |E-IP |
| | |Stack AS| |Only AS| |Only AS|
+--------+ +--------+ +-------+ +-------+
| | | |
| | | |
+----+ +----+ +----+ +----+
+-|I-IP|------|AFBR|------|I-IP|-----|AFBR|-+
| +----+ +----+ +----+ +----+ |
CN9 | R32 R33 R34 R35 |
+-------+ +----+ |
|Client |----|AFBR| S-AS3 |
|Network| +----+R31 |
+-------+ | |
+-------------------------------------------+
Figure 4: Example inter-AS softwires deployment with other types of
networks. S-AS1, S-AS2, and S-AS3 form the softwires cloud.
What does it mean to be "part of the softwires cloud"? It means
that all E-IP packets that traverse the cloud must be transmitted
over I-IP softwires, because there are routers in the participating
ASes that cannot forward E-IP packets. This in turn implies that
every S-AS participating in the cloud must deploy an AFBR with all
ASes that operate the E-IP and are not in the cloud. As such, in
Figure 4, S-AS1 must deploy AFBRs at the interface with the Dual
Stack AS and the E-IP Only AS (as well as with the Client Network).
Note that the Dual Stack AS in principle could join the softwires
cloud, since it is capable of carrying packets tunneled in the I-IP.
If it did, however, then either there would still have to be an AFBR
at the edge of S-AS1 and the Dual Stack AS, or the Dual Stack AS
would have to deploy an AFBR at the border with every AS operating
the E-IP and not in the cloud. Otherwise, one of those ASes could
send a native E-IP packet with a destination address in CN8 into the
Xu, et al. Expires April 19, 2010 [Page 9]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
Dual Stack AS, which would not be able to forward it to S-AS1 even
though S-AS1 advertised the prefix for CN8.
Let's consider an example of BGP using Tunnel Endpoint Attribute in
Figure 4. Suppose that CN8 advertises an E-IP prefix to S-AS1.
AFBR R11 in S-AS1 attaches the Tunnel Endpoint Attribute with its
own I-IP address to the update, and forwards it to R12, R13, R14 and
R15 via iBGP. Because S-AS2 is part of the softwires cloud, R12
advertises the CN8 prefix to S-AS2, even though R12 is not capable
of forwarding E-IP packets. As AFBRs, R13 and R15 advertise the CN8
prefix to the Dual Stack and E-IP Only ASes, but without the Tunnel
Endpoint Attribute. The prefix for CN8 is not advertised to the I-
IP Only AS since it doesn't support E-IP control plane. R14 does,
however, advertise I-IP BGP prefixes to the I-IP Only AS so as to
allow I-IP packets to reach S-AS1.
The prefix for CN8 reaches S-AS3 at three points, R32, R33, and R35.
The latter two attach the Tunnel Endpoint Attribute with themselves
as the tunnel endpoint since they are AFBRs, while R32 still keeps
Tunnel Endpoint Attribute to be the I-IP address of R11. R31 will
receive prefix for CN8 from R32, R33, and R35 respectively. Finally,
the prefix for CN8 is advertised to CN9 from R31. Note now that
packets from CN9 to CN8 may traverse any of the four intervening
ASes. If R31 chooses to use intra-AS softwire, then the packet
encapsulated by R31 will either reach R33, get decapsulated and go
through the Dual Stack AS to reach S-AS1 at R13 for the second-time
tunneling from R13 to R11, or get decapsulated at R35, and reach S-
AS1 through the E-IP Only AS and then tunneled from R15 to R11. If
R31 chooses to use inter-AS softwire, the packets will be
encapsulated at R31 and decapsulated at R11. This tunneled packet,
however, may traverse any of S-AS2, the Dual Stack AS, or the I-IP
Only AS, depending on which best path was selected for the prefix
holding the tunnel address for R11. Note in particular that the AS
path taken by the tunneled packet from ingress AFBR to egress AFBR
may not be the AS path indicated in the E-IP BGP update, because BGP
decision process for I-IP and E-IP routes are independent.
In any event, this example illustrates that inter-AS softwires is
quite robust. As long as there is any E-IP BGP control-plane path
between two E-IP Client Networks, any path to the tunnel endpoint
address can be used to transmit the tunneled packets.
3.3. Aggregation consideration
When multiple routes with different tunnel endpoint addresses are
aggregated, the aggregating router must attach a Tunnel Endpoint
Xu, et al. Expires April 19, 2010 [Page 10]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
Attribute with its own address as the tunnel endpoint. This is
illustrated in Figure 5 below.
+------------------------+
| |
| S-AS1 |
| |
| |
| |
+------------------------+
|
3.3.3.0/24 |
TE=2.2.2.5 |
+-----+
+--------|AFBR3|---------+
| +-----+ |
| S-AS2 |
| |
| |
|3.3.3.0/25 3.3.3.128/25|
|TE=2.2.2.1 TE=2.2.2.2 |
| +-----+ +-----+ |
+--|AFBR1|----|AFBR2|----+
+-----+ +-----+
| |
| |
+---------+_ +--------+
| CN1 | | CN2 |
+---------+ +--------+
3.3.3.0/25 3.3.3.128/25
Figure 5: Example of Aggregation
Here, S-AS2 wishes to aggregate its customer Client Networks
3.3.3.0/25 and 3.3.3.128/25 into a single aggregated 3.3.3.0/24. In
order to do this, its border router with S-AS1 (i.e. AFBR3) replace
the two different received tunnel endpoint addresses (2.2.2.1 and
2.2.2.2) with its own (2.2.2.5) and then advertise the aggregated
route to S-AS1. There are two important things to notice here.
First, whereas in previous examples (i.e. Figure 4), the border
routers between two S-ASes were not AFBRs. Aggregating routers,
however, must be AFBRs because they advertise themselves as tunnel
endpoints.
Xu, et al. Expires April 19, 2010 [Page 11]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
3.4. Summary of Inter-AS softwires rules
1. Inter-AS softwires deployment consists of a contiguous set of two
or more participating ASes (S-ASes) called a softwire cloud. All
ASes in the softwires cloud must deploy AFBRs at the border of
all E-IP capable ASes that are not part of the softwires cloud.
All other AS border routers must be able to process both E-IP and
I-IP BGP (i.e. must be support extended MP-BGP to do E-IP prefix
routing besides native I-IP BGP), but only need I-IP capability
in the data plane.
2. All AFBRs must attach the Tunnel Endpoint Attribute to E-IP
routes that enters the softwire cloud.
3. All AFBRs must remove the Tunnel Endpoint Attribute on E-IP
routes that leaves the softwire cloud.
4. If an AFBR selects as its best path a route with an associated
Tunnel Endpoint Attribute, then the AFBR must use the tunnel to
forward packets on that route.
5. Routers within an S-AS must not remove a Tunnel Endpoint
Attribute from an update.
6. When aggregating two or more routes with different Tunnel
Endpoint Attributes, the aggregating router must strip the
original Tunnel Endpoint Attributes, and add its own Tunnel
Endpoint Attribute to the aggregated route.
4. 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
softwires described here. The difference is, where the RFC5565
security considerations apply to an "administrative domain", here
they must apply to the entire softwires cloud (i.e. the set of ASes
participating in the establishment of inter-domain softwires). In
Xu, et al. Expires April 19, 2010 [Page 12]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
particular, the security mechanisms in RFC5565 require
administrative coordination between the ingress border router and
the tunnel endpoint. In the case of RFC5565 softwires, these two
routers are in the same administrative domain. In the case of
inter-domain softwires, they are in different domains. That mere
fact that two or more domains choose to cooperate to form a
softwires cloud in the first place, however, suggests that there is
some administrative cooperation between them. This cooperation may
be leveraged to provide the administrative coordination needed to
deploy the security techniques described in RFC5565.
5. IANA Considerations
IANA must issue a new Sub-Type for the Address Specific BGP Extended
Communities Attribute.
6. Acknowledgments
The author would like to thank Eric Rosen for his valuable comments.
7. Document Changes
7.1. Changes from draft-xu-idr-tunnel-00.txt
1. The document is renamed as draft-xu-tunnel-00.txt.
2. The need for a new sub-TLV definition in [I-D.ietf-softwire-
encaps-safi] has been eliminated (in favor of the Address Specific
BGP Extended Communities Attribute).
3. The need to carry the AS number of the originating AS separate
from the AS-Path attribute has been eliminated.
4. The requirement that the AS-path to the tunnel endpoint address
and the AS-path to the destination prefix be the same was
dropped. As a result, however, legacy ASes may believe that
packets take a different AS-path than the one they actually take.
5. The mechanism to avoid transient loops between providers of
multi-homed sites has been made optional rather than required.
7.2. Changes from draft-xu-tunnel-00.txt
1. The document is renamed as draft-xu-softwire-tunnel-endpoint-
00.txt.
Xu, et al. Expires April 19, 2010 [Page 13]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
2. The inter-AS softwire is used as an application scenario for the
tunnel endpoint attribute, and the corresponding usage is also
described in this document.
3. New co-authors are added.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[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.
[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.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 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.
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
Xu, et al. Expires April 19, 2010 [Page 14]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP October 2009
Gottlieb-Daimler-Strasse
Kaiserslautern 67633
Germany
Phone: +49 631 930 39600
Email: francis@mpi-sws.org
Yong Cui
Tsinghua University
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 April 19, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 10:44:57 |