Network Working Group Gargi Nalawade
Internet Draft Ruchi Kapoor
Expires: January 2006 Dan Tappan
Scott Wainner
Cisco Systems
Tunnel SAFI
draft-nalawade-kapoor-tunnel-safi-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Abstract
The architecture of an MPLS VPN solution relies on the establishment
of two layers of reachability information. The first is the
association of a prefix, interface, or route table to a VPNv4 label
that is used on the egress PE to delineate a Virtual Route Forwarding
table. The second is the association of the next-hop to reach the
egress PE. By default, the MPLS VPN establishes an LSP tunnel from
the ingress PE to the egress PE. A requirement exists to establish
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 1]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
an IP tunnel between the ingress and egress PE in lieu of an LSP.
The egress PE's tunnel capability needs to be distributed to all the
potential ingress PE's as well as the attributes of the tunnel. The
tunnel end-point discovery may occur within and across Autonomous
Systems. BGP is the logical protocol of choice that is widely
deployed for MPLS VPN solutions and can carry this information in a
synchronized manner. This document defines how BGP speakers can
convey Tunnel end-point reachability information.
1. Introduction
Two end-points of a tunnel need to agree upon the end-point
information and its binding to a network address at the remote point.
Normally, this information can be manually shared and statically
configured when the number of tunnels to manage is relatively small.
In the case of a network such as an MPLS VPN where there is a need
for a tunnel between every ingress and egress PE, the number of
tunnel end-points that need to be exchanged and maintained grows
dramatically as the network becomes large. The egress PE already
defines reachability information for the private routing information
as well as the NLRI of the PE itself. This information is
distributed via MP-BGP to any number of potential ingress PE. The
extent of distribution of egress PE's NLRI and next-hop is unknown by
the egress PE; therefore, egress PE cannot feasibly know the tunnel
attributes for any potential ingress PE unless the egress PE assigns
these attributes. The egress PE needs to advertise it's capability
to receive tunneled packets, the types of tunnels supported, the
preference for the various tunnel methods, and the attributes
associated with the tunnels. The tunnel information then needs to be
distributed and maintained using MP-BGP such that every potential
ingress PE knows the appropriate tunnel method and attributes of the
egress PE. The tunnel capabilities are uniquely defined for a given
PE and may or may not correlate with the capabilities of any other
potential ingress PE. For this reason, the ingress PE may select the
most appropriate tunneling mechanism based on the compability of the
tunnel capabilities between the ingress and egress PE's and their
preferences.
2. The Tunnel SAFI
This document defines a new BGP SAFI called the Tunnel SAFI. The
<AFI, SAFI> [IANA-AFI] [IANA-SAFI] value pair used to identify this
SAFI are- AFI=1, SAFI=64, for the IPv4 Tunnel AFI; and AFI=2, SAFI=64
for the IPv6 Tunnel AFI.
For BGP Speakers supporting [BGP-4], the tunnel end point address
will be carried as an NLRI in the MP_REACH attribute for the Tunnel
SAFI.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 2]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
The NLRI will be encoded as a 2-octet Identifier followed by the NLRI
format as specified by the respective AFI. The Identifier will
identify the tunnel end point being advertised. This Identifier
enables multiple tunnel end-points to share the same network address,
thus conserving the number of addresses needed to be configured by
the operator on each of the Tunnel-endpoints.
3. BGP Attribute
The BGP SSA Attribute [BGP-SSA] will be used to carry the Tunnel
end-point information. The egress PE may support one or more tunnel
methods. The egress PE MUST advertise all tunnel types for which it
will support tunnel termination. The egress PE MAY advertise one or
more tunnel types. And update for the Tunnel SAFI MUST never be sent
without the BGP SSA Attribute.
As defined in [BGP-TUN], the first bit of the TYPE field in the BGP
SAFI-Specific Attribute is the 'transitive bit'. If the bit value is
1, implies that this tunnel is transitive. If the bit value is 0, it
implies this specific tunnel is not transitive.
The Value Field of the BGP SSA Attribute, MUST contain at least one
of the following valid Type codes for this SAFI. It MAY contain one
or more TLVs with these Type codes.
Type 1: L2TPv3 Tunnel information
Type 2: mGRE Tunnel information
Type 3: IPSec Tunnel information
Type 4: MPLS Tunnel information
Type 5: L2TPv3 in IPSEC Tunnel information
Type 6: mGRE in IPSEC Tunnel information
3.1. L2TPv3 Tunnel information TLV
The L2TPv3 Tunnel Information TLV has a type value of 1. The value
part of the L2TPv3 Tunnel Information Type contains the following :
- Preference (2 Octets)
- Flags (1 Octet)
- Cookie Length (1 Octet)
- Session ID (4 Octets)
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 3]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
- Cookie (Variable)
The L2TPv3 Tunnel Information TLV looks as follows :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Flags | Cookie Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 Octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
Length - A 2 Octet field that specifies the length of the L2TPv3
attribute in octets. The value contained in this Length field MUST
not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus
the total length of any prior TLVs.
Preference - A 2 Octet field containing a Preference associated with
the TLV. The Preference value indicates a preferred ordering of
tunneling encapsulations according to the sender (i.e. egress PE).
The recipient of the information SHOULD take the sender's preference
into account in selecting which encapsulation it will use. A higher
value indicates a higher preference.
Flags - A 1 Octet field containing flag-bits. The leftmost bit
indicates whether Sequence numbering is to be used or not. The
remaining bits are reserved for future use.
Cookie Length - is a 1 Octet field that contains the length of the
Variable length Cookie.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 4]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
Session ID - A 4 Octet field containing a non-zero identifier for a
session. The Session ID is used to delineate services on the egress
PE. The support for a service such as MPLS VPN MUST have at least
one Session ID assigned. Multiple Session ID's may be assigned for
the same service instance. The primary motivation for assigning
multiple Session ID's for the same service instance is provide a
graceful transition when changing cookie values. The egress PE can
receive both Session ID's with their unqiue Cookie value thus
allowing a graceful roll-over from an old Session ID and Cookie to a
new Session ID and Cookie. Alternatively, multiple service instances
may be distributed across multiple processes in order to scale. Each
service instance may be assigned a unique Session ID and Cookie and
advertised by BGP such that packets received from the ingress PE are
directed to the appropriate service instance on the egress PE.
Cookie - Cookie is a variable length (maximum 64 bits), value used by
L2TPv3 to check the association of a received data message with the
session identified by the Session ID. The Cookie value is tightly
coupled with the Session ID. Upon the generation of a Session ID by
the egress PE, the associated Cookie MAY be generated such that
packets received by the egress PE from an ingress PE can be quickly
validated for proper service context.
The default value of the Length Field for the L2TPv3 Tunnel
information TLV is between 8 and 16 bytes, depending on the length of
the Cookie field specified in Cookie length. If the length of the TLV
is greater than that value, the subsequent portion of the Value field
contains one or more sub-TLVs as defined in [BGP-SSA].
3.2. mGRE Tunnel Information TLV
The mGRE Tunnel Information Type has a Type 2. The value part of the
mGRE Tunnel Information Type contains the following :
- Preference (2 Octets)
- Flags (1 Octet)
- mGRE Key (0 or 4 Octets)
The mGRE Tunnel Information TLV looks as follows :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 5]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|K| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mGRE Key (4 Octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length - A 2 Octet field that specifies the length of the mGRE
information in octets. The value contained in this Length field MUST
not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus
the total length of any prior TLVs. (This doesn't make sense to me.
What's the relationship between TLV's?)
Preference - A 2 Octet field containing a Preference associated with
the TLV. The Preference value indicates a preferred ordering of
tunneling encapsulations according to the sender (i.e. egress PE).
The recipient of the information (i.e. ingress PE) SHOULD take the
sender's preference into account in selecting which encapsulation it
will use. A higher value indicates a higher preference.
Flags - A 1 Octet field containing flag-bits. The leftmost bit
indicates whether Sequence numbering is to be used or not. The 2nd
bit Indicates whether an mGRE Key is present or not. The Remaining
bits are reserved for future use.
Reserved - A 1 Octet field reserved for future use
mGRE Key - A 4 Octet field containing an optional mGRE Key. The key
value may be generated by the egress PE and advertised by the egress
PE to any potential ingress PE. In this case, the key value has
unidirectional relevance from all viable ingress PE's to the egress
PE. Alternatively, the key value may be statically configured such
that all ingress and egress PE's use the same key value.
If the Length field of the TLV contains a value greater than 3 Octets
plus the value specified in the Key Length, the subsequent portion of
the Value field contains one or more sub-TLVs as defined by [BGP-
SSA].
3.3. IPSec Tunnel Information TLV
The IPSec Tunnel Information Type has a Type 3. The value part of
the IPSec Tunnel Information Type contains the following :
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 6]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
- Preference (2 Octets)
- Flags (1 Octet)
- IKE ID Type (1 Octets)
- IKE ID Length (2 Octets)
- IKE Identifier (Variable)
The IPSec Tunnel Information TLV looks as follows :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IKE_ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE_LNG (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE Identifier (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length - A 2 Octet field that specifies the length of the IPSec
information in octets. The value contained in this Length field MUST
not exceed the total length of the BGP SSA [BGP-SSA] Attribute minus
the total length of any prior TLVs.
Preference - A 2 Octet field containing a Preference associated with
the TLV. The Preference value indicates a preferred ordering of
tunneling encapsulations according to the sender. The recipient of
the information SHOULD take the sender's preference into account in
selecting which encapsulation it will use. A higher value indicates a
higher preference.
Flags - A 1 Octet field containing flag-bits.
IKE_ID Type - This 1 Octet field identifies the type of IKE
Identifier used by the egress PE
IKE_LNG - This 2 Octet field indicates the length of the IKE
Identifier.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 7]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
IKE Identifier - A variable length field containing an IKE Identifier
of the egress PE.
If the Length field of the TLV contains a value greater than 11
Octets plus the value specified in the Key Length, the subsequent
portion of the Value field contains one or more sub-TLVs as defined
by [BGP-SSA].
3.4. MPLS TLV
The MPLS TLV has a Type 4. The value part of the MPLS TLV contains
the following :
- Preference (2 Octets)
- Flags (1 Octet)
The MPLS Tunnel Information TLV looks as follows :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+
Length A 2 Octet field that specifies the length of the MPLS TLV in
octets. The value contained in this Length field MUST not exceed the
total length of the BGP SSA [BGP-SSA] Attribute minus the total
length of any prior TLVs.
Preference A 2 Octet field containing a Preference associated with
the TLV. The Preference value indicates a preferred ordering of
tunneling encapsulations according to the sender. The recipient of
the information SHOULD take the sender's preference into account in
selecting which encapsulation it will use. A higher value indicates a
higher preference.
Flags - A 1 Octet field containing flag-bits.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 8]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
3.5. L2TPv3 in IPSEC TLV
When the value in the Type field is 5, the Value portion of the
SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an
L2TPv3 TLV.
3.5. mGRE in IPSEC TLV
When the value in the Type field is 6, the Value portion of the
SAFI-Specific Attribute TLV will carry an IPSec TLV followed by an
mGRE TLV.
4. Capability Advertisement
A BGP speaker MAY participate in the distribution of the IPv4-Tunnel
SAFI or IPv6-Tunnel SAFI information. A BGP speaker that wishes to
exchange the IPv4-Tunnel SAFI or the IPv6 Tunnel SAFI, MUST use the
MP_EXT Capability Code as defined in [BGP-MP], to advertise the
corresponding (AFI, SAFI) pair.
5. Operation
A BGP Speaker that receives the Capability for the IPv4-Tunnel SAFI
or the IPv6-Tunnel SAFI, MAY advertise the IPv4-Tunnel SAFI or IPv6-
Tunnel SAFI prefixes to that peer.
The BGP SSA Attribute is defined only to be used in UPDATE messages
for the IPv4 tunnel SAFI or the IPv6 Tunnel SAFI. If the BGP SSA
Attribute is received in an UPDATE message for any other AFI/SAFI, it
MUST be ignored.
If a BGP Speaker receives an unrecognized Transitive Tunnel TLV as
part of the BGP SSA Attribute, it MUST accept it and propagate it to
other peers.
6. Deployment Considerations
In order for the Tunnels to come up between two end-points, the BGP
Speakers advertising the Tunnel end-points using the IPv4/IPv6 Tunnel
SAFI, MUST exchange at least one common encapsulation option.
7. Applicability
7.1. IPSec Tunnels Applicability
IPSec protection of IP routed packets requires the establishment of
an IPSec proxy that specifies the source and destination range of
addresses that require protection. The synchronization of the IPSec
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 9]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
proxy and the viability of the path to the destination IP address
range has been a persistent problem in the deploy of IPSec solutions.
The IPSec proxy must be associated with an IKE end-point identifier.
IPSec is inherently a tunneling protocol; however, it has no means of
synchronizing the viability of the destination path in the IPSec
proxy. One approach to synchronizing the IPSec proxy, the IKE end-
point and the path viability is to leverage BGP Tunnel SAFI. The BGP
protocol provides a means of distributing the destination address
range of the IPSec proxy via the NLRI. The IKE end-point identifier
may be consistent with the BGP next-hop and may be specified by the
TLVs in the BGP SSA Attribute [BGP-SSA]
in the BGP Tunnel SAFI. An IPSec end-point that receives a BGP
announcement may qualify the update and use the NLRI prefix as the
destination range in the IPSec proxy. The IPSec end-point may learn
the remote peer's IKE identity that is defined by the next-hop
attribute of the Tunnel SAFI. The route viability is Inherently
conveyed via the BGP protocol. The combination of the traditional IP
NLRI and the Tunnel NLRI allows IPSec to automatically establish the
connection attributes required to protect IP traffic between the two
end-points.
7.2. IP Tunnels Applicability
Multiprotocol Label Switching (MPLS) VPN introduced a peer-to-peer
model that enables large scale IP VPN implementations. Traditional
MPLS VPNs rely on an MPLS transport network to implement this peer-
to-peer model. 'MPLS VPN over IP Tunnels' reuses the same
functionality, but replaces the MPLS transport with an IP transport.
VPN traffic is carried by an IP tunnel instead of an MPLS Label
Switched Path (LSP). The VPN customer receives the same service
experience regardless of the transport choice used by the service
provider.
MPLS VPN uses the same mechanisms for VPN route distribution
regardless of the backbone transport choice (IP or MPLS). Customer
edge (CE) devices exchange routing information with the provider edge
(PE) devices using BGP or an Interior Gateway Protocol (IGP)
protocol. This routing information is exchanged between PEs using
Multi-Protocol BGP (MP-BGP). VPN routing information is carried by
MP-BGP as VPNv4 addresses. As part of this VPN route exchange, PEs
learn the nexthop (egress PE) and a VPN label to be associated with
each VPN route.
Before proper VPNv4 BGP next hop resolution can take place, each PE
needs to know which other PEs (i.e. Tunnel endpoints) are reachable
via the IP tunnel.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 10]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
The Tunnel SAFI update messages provide a means of distributing the
Tunnel endpoint address as the NLRI in the Tunnel SAFI UPDATE. The
Tunnel endpoint address should be consistent with the BGP next-hop in
the VPNv4 update messages. This information is used to determine
which IP tunnel needs to be used for which VPNv4 prefixes.
In addition, each PE needs to know the tunnel attributes (used to
define this tunnel) that other PEs expect, so VPN packets can be
encapsulated appropriately. Manual configuration of this information
is not scalable, as the number of PEs increases. A PE that receives
the Tunnel SAFI update may use the tunnel NLRI prefix and the tunnel
attributes specified by the other end, and try and establish a tunnel
to that endpoint. PEs take advantage of the existing MP-BGP
infrastructure to distribute tunnel endpoint information. The Tunnel
SAFI UPDATE message is used to signal tunnel attribute and endpoint
information amongst PEs. And thus tunnel endpoint discovery is
accomplished using MP-BGP updates.
8. Security Considerations
This extension to BGP does not change the underlying security issues.
9. Acknowledgements
We would like to thank Jim Guichard, Francois LeFaucher for their
contribution. We would like to thank Arjun Sreekantiah, Shyam Suri,
Chandrashekhar Appanna, John Scudder and Mark Townsley for their
comments and suggestions.
10. References
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace
[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
[BGP-SSA] Kapoor R., Nalawade G., "BGPv4 SAFI-Specific Attribute",
draft-nalawade-kapoor-idr-bgp-ssa-01.txt, work in progress.
[MULTI-BGP] Bates et al, "Multiprotocol Extensions for BGP-4", draft-
ietf-idr-rfc2858bis-02.txt, work in progress.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 11]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
11. Authors' Addresses
Gargi Nalawade
Cisco Systems, Inc
170 West Tasman Drive
San Jose, CA 95134
mailto:gargi@cisco.com
Ruchi Kapoor
Cisco Systems, Inc
170 West Tasman Drive
San Jose, CA 95134
mailto:ruchi@cisco.com
Dan Tappan
Cisco Systems, Inc
170 West Tasman Drive
San Jose, CA 95134
mailto:tappan@cisco.com
Scott Wainner
Cisco Systems, Inc
13600 Dulles Technology Drive
Herndon, VA 20171
mailto:swainner@cisco.com
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 12]
Internet Draft draft-nalawade-kapoor-tunnel-safi-03.txt July 2005
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Expiration Date
This memo is filed as <draft-nalawade-kapoor-tunnel-safi-03.txt>, and
expires January, 2006.
draft-nalawade-kapoor-tunnel-safi-03.txt [Page 13]