One document matched: draft-xu-softwire-tunnel-endpoint-01.txt
Differences from draft-xu-softwire-tunnel-endpoint-00.txt
Network working group X. Xu
Internet Draft Huawei
Category: Standard Track P. Francis
Expires: August 2010 MPI-SWS
Y. Cui
Tsinghua University
February 23, 2010
Simple Tunnel Endpoint Signaling in BGP
draft-xu-softwire-tunnel-endpoint-01
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 August 23, 2010.
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 August 23, 2010 [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) softwires, but not inter-AS softwires. The ability to
provide inter-AS softwires extends the benefits of softwires to a
larger scale. Indeed, the above Framework discusses the possibility
of inter-AS softwires, 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 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
1.1. Terminology..............................................3
1.2. Background...............................................3
2. Syntax of the Tunnel Endpoint Attribute.......................8
3. Usage of the Tunnel Endpoint Attribute........................8
3.1. Cooperate with other BGP extensions for softwire.........8
3.2. Inter-AS and Intra-AS mixed scenario.....................9
3.3. Aggregation consideration...............................11
3.4. Summary of Inter-AS softwires rules.....................12
4. Security Considerations......................................13
5. IANA Considerations..........................................14
6. Acknowledgments..............................................14
7. Document Changes.............................................14
7.1. Changes from draft-xu-idr-tunnel-00.txt.................14
7.2. Changes from draft-xu-tunnel-00.txt.....................14
7.3. Changes from draft-xu-softwire-tunnel-endpoint-00.txt...15
8. References...................................................15
8.1. Normative References....................................15
8.2. Informative References..................................15
Authors' Addresses..............................................15
Xu, et al. Expires August 23, 2010 [Page 2]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
1. Introduction
The Softwire Mesh Framework [RFC5565] provides a solution for intra-
Autonomous System (AS) softwires, but not inter-AS softwires. The
ability to provide inter-AS softwires extends the benefits of
softwires to a larger scale. RFC 5565 discusses the possibility of
inter-AS softwires, but does not provide a solution. This document
defines a specific BGP4 Extended Community attribute called the
Tunnel Endpoint attribute, which allows for inter-AS softwires.
1.1. Terminology
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).
1.2. Background
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 RFC 5565 problem,
consider the following scenario (As illustrated in Figure 1):
Xu, et al. Expires August 23, 2010 [Page 3]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
+-----------------+
+-------+ | |
| 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 Address Family Border Router
(AFBR) to the egress AFBR. The packet is de-tunneled at the egress
AFBR, and then re-tunneled by 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 (As illustrated in 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 Multi-Protocol BGP (MP-BGP) capability to transmit E-
IP routes and tunnel signaling parameters, which we refer to as MP-
BGP control plane in this draft. Note that this could also be an
IPv6 transit supporting IPv4 client networks.
Xu, et al. Expires August 23, 2010 [Page 4]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
+-----------------+
+-------+ | 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: Inter-AS Softwire Scenario 1
Now consider another inter-AS softwire scenario as illustrated in
Figure 3. Here, there is a transit network between two AFBR-capable
transits that does not operate any AFBR. RFC 5565 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 August 23, 2010 [Page 5]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
+-----------------+
+-------+ | 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: Inter-AS Softwire Scenario 2
RFC 5565 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.
3. 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.
The first approach results in reduced forwarding performance for
many routers. This is because of the extra tunneling operations,
and because IPv6 forwarding is slower than IPv4 forwarding (for
Xu, et al. Expires August 23, 2010 [Page 6]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
IPv6-over-IPv4 scenario). What's more, it does not apply to the
scenario in Figure 3 because there are no AFBRs deployed in AS2.
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 BGP 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 draft proposes the Tunnel Endpoint
attribute: an attribute that carries the address of the tunnel
endpoint and is transitive across ASes. 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.
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 limited or non-functioning 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 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
Xu, et al. Expires August 23, 2010 [Page 7]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
networks could be IPv6 networks with limited or non-functioning 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], respectively) to
carry the tunnel endpoint address. 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 (RFC 4798, RFC 5549,
RFC 5512) are all defined under the scope of RFC 5565, or we say,
these extensions were created to be used in the intra-AS scenario,
it's necessary that we verify them for the inter-AS scenario, to
ensure that they also work with the Tunnel Endpoint Attribute.
The extensions for softwire routing E-IP prefix in I-IP network are
defined in RFC 4798 and RFC 5549, 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
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 RFC
4798 and RFC 5549.
Xu, et al. Expires August 23, 2010 [Page 8]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
RFC 5512 provide two approaches to do tunnel signaling. The first
one uses the Tunnel Encapsulation Attribute. Tunnel Encapsulation
Attribute is already defined as a transitive attribute and will be
passed through the intermediate BGP routers. The second approach
uses 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 also 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 August 23, 2010 [Page 9]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
+-------------------------------------------+
| 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: Inter-AS Softwires Deployment Example.
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
Dual Stack AS, which would not be able to forward it to S-AS1 even
though S-AS1 advertised the prefix for CN8.
Xu, et al. Expires August 23, 2010 [Page 10]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
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, be decapsulated and go
through the Dual Stack AS to reach S-AS1 at R13 for the second-time
tunneling from R13 to R11, or the packet will be 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
Attribute with its own address as the tunnel endpoint. This is
illustrated in Figure 5 below.
Xu, et al. Expires August 23, 2010 [Page 11]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
+------------------------+
| |
| 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) replaces
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 advertises 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.
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
Xu, et al. Expires August 23, 2010 [Page 12]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
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 enter the softwire cloud.
3. All AFBRs must remove the Tunnel Endpoint Attribute on E-IP
routes that leave 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 RFC 5565
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
particular, the security mechanisms in RFC 5565 require
administrative coordination between the ingress border router and
the tunnel endpoint. In the case of RFC 5565 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
Xu, et al. Expires August 23, 2010 [Page 13]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
some administrative cooperation between them. This cooperation may
be leveraged to provide the administrative coordination needed to
deploy the security techniques described in RFC 5565.
5. 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.
6. Acknowledgments
The authors would like to thank Eric Rosen and Spencer Dawkins for
their 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.
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.
Xu, et al. Expires August 23, 2010 [Page 14]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
7.3. Changes from draft-xu-softwire-tunnel-endpoint-00.txt
1. Some editorial errors are corrected.
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.
[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.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the
BGP Tunnel Encapsulation Attribute", RFC 5512, April
2009.
8.2. Informative References
[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.
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
Xu, et al. Expires August 23, 2010 [Page 15]
Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010
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| PAFTECH AB 2003-2026 | 2026-04-23 10:40:36 |