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]