< draft-ietf-isis-admin-tags-03.txt   draft-ietf-isis-admin-tags-04.txt >
IS-IS Working Group Christian Martin Network Working Group S. Previdi
Verizon Internet-Draft M. Shand, Ed.
IETF Internet Draft Stefano Previdi Intended status: Standards Track Cisco Systems
Cisco Systems Expires: May 22, 2008 C. Martin
Brad Neal Verizon
Broadwing Communications B. Neal
Broadwing Communications
November 19, 2007
Expires: August 2005 February 2005 A Policy Control Mechanism in IS-IS Using Administrative Tags
draft-ietf-isis-admin-tags-04.txt
A Policy Control Mechanism in IS-IS Using Administrative Tags Status of this Memo
<draft-ietf-isis-admin-tags-03.txt> 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.
Status of this Memo 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.
By submitting this Internet-Draft, I certify that any applicable Internet-Drafts are draft documents valid for a maximum of six months
patent or IPR claims of which I am aware have been disclosed, and any and may be updated, replaced, or obsoleted by other documents at any
of which I become aware will be disclosed, in accordance with RFC time. It is inappropriate to use Internet-Drafts as reference
3668. material or to cite them other than as "work in progress."
This document is an Internet-Draft and is in full conformance with The list of current Internet-Drafts can be accessed at
all provisions of Section 10 of RFC2026. Internet-Drafts are working http://www.ietf.org/ietf/1id-abstracts.txt.
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 The list of Internet-Draft Shadow Directories can be accessed at
and may be updated, replaced, or obsoleted by other documents at any http://www.ietf.org/shadow.html.
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 This Internet-Draft will expire on May 22, 2008.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Abstract Copyright (C) The IETF Trust (2007).
This document describes an extension to the IS-IS protocol to add Abstract
operational capabilities that allow for ease of management and
control over IP prefix distribution within an IS-IS domain. This
document enhances the IS-IS protocol by extending the information
that a Intermediate System (IS) [router] can place in Link State
Protocol Data Units (LSPs) for policy use. This extension will
provide operators with a mechanism to control IP prefix distribution
throughout multi-level IS-IS domains. Additionally, the information
can be placed in LSPs that have TLVs as yet undefined, if this
information is used to convey the same meaning in these future TLVs
as it is used in the currently defined TLVs.
Conventions used in this document This document describes an extension to the IS-IS protocol to add
operational capabilities that allow for ease of management and
control over IP prefix distribution within an IS-IS domain. This
document enhances the IS-IS protocol by extending the information
that adraft-ietf-isis-wg-multi-topology Intermediate System (IS)
[router] can place in Link State Protocol Data Units (LSPs) for
policy use. This extension will provide operators with a mechanism
to control IP prefix distribution throughout multi-level IS-IS
domains.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Table of Contents
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
1. Introduction 1. Conventions used in this Document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 4
3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 4
4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 4
5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Manageability Considerations . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
As defined in [2] and extended in [3], the IS-IS protocol may be used 1. Conventions used in this Document
to distribute IPv4 prefix reachability information throughout an IS-
IS domain. In addition, thanks to extensions made in [6] and [7], IS-
IS may be used to distribute IPv6 reachability information.
The IPv4 prefix information is encoded as TLV type 128 and 130 in The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
[2], with additional information carried in TLV 135 as specified in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
[3] and TLV 235 as defined in [6]. In particular, the extended IP document are to be interpreted as described in BCP 14, [RFC2119].
Reachability TLV (TLV 135) contains support for a larger metric
space, an up/down bit to indicate redistribution between different
levels in the hierarchy, an IP prefix, and one or more sub-TLVs that
can be used to carry specific information about the prefix. TLV 235
is a derivative of TLV 135, with the addition of Multi-Topology
membership information [6]. The IPv6 prefix information is encoded as
TLV 236 in [7] and TLV 237 in [6].
As of this writing no sub-TLVs have been defined; however, this draft 2. Introduction
proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237
that may be used to carry administrative information about an IP
prefix.
2. Sub-TLV Additions As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol
[ISO10589] may be used to distribute IPv4 prefix reachability
information throughout an IS-IS domain. In addition, thanks to
extensions made in [I-D.ietf-isis-wg-multi-topology] and
[I-D.ietf-isis-ipv6], IS-IS may be used to distribute IPv6
reachability information.
This draft proposes 2 new "Administrative Tag" sub-TLVs to be added The IPv4 prefix information is encoded as TLV type 128 and 130 in
to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or [RFC1195], with additional information carried in TLV 135 as
more ordered, 32 or 64 bit unsigned integers that may be associated specified in [RFC3784] and TLV 235 as defined in
with an IP prefix. Example uses of these tags include controlling [I-D.ietf-isis-wg-multi-topology]. In particular, the extended IP
redistribution between levels and areas, different routing protocols, Reachability TLV (TLV 135) contains support for a larger metric
or multiple instances of IS-IS running on the same router, or space, an up/down bit to indicate redistribution between different
carrying BGP standard or extended communities. levels in the hierarchy, an IP prefix, and one or more sub-TLVs that
can be used to carry specific information about the prefix. TLV 235
is a derivative of TLV 135, with the addition of Multi-Topology
membership information [I-D.ietf-isis-wg-multi-topology]. The IPv6
prefix information is encoded as TLV 236 in [I-D.ietf-isis-ipv6] and
TLV 237 in [I-D.ietf-isis-wg-multi-topology].
The methods for which their use is employed is beyond the scope of This draft proposes 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and
this document and left to the implementer and/or operator. TLV 237 that may be used to carry administrative information about an
IP prefix.
The encoding of the sub-TLV(s) is discussed in the following 3. Sub-TLV Additions
subsections.
2.1. 32-bit Administrative Tag Sub-TLV 1 This draft proposes 2 new "Administrative Tag" sub-TLVs to be added
to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or
more 32 or 64 bit unsigned integers that may be associated with an IP
prefix. Example uses of these tags include controlling
redistribution between levels and areas, different routing protocols,
or multiple instances of IS-IS running on the same router, or
carrying BGP standard or extended communities.
The Administrative Tag SHALL be encoded as one or more 4 octet The methods for which their use is employed is beyond the scope of
unsigned integers using Sub-TLV 1 in TLV-135 [3], TLV 235 [6], TLV this document and left to the implementer and/or operator.
236 [7] and TLV 237 [6]. The Administrative Tag Sub-TLV has following
structure:
1 octet of type (value: 1) The encoding of the sub-TLV(s) is discussed in the following
1 octet of length (value: multiple of 4) subsections.
one or more instances of 4 octets of administrative tag
An implementation MAY consider only one of the encoded tags, in which 3.1. 32-bit Administrative Tag Sub-TLV 1
case the first encoded tag MUST be considered. A tag value of zero
is reserved and SHOULD be treated as "no tag".
2.2. 64-bit Administrative Tag Sub-TLV 2 The Administrative Tag SHALL be encoded as one or more 4 octet
unsigned integers using Sub-TLV 1 in TLV-135 [RFC3784], TLV 235
[I-D.ietf-isis-wg-multi-topology], TLV 236 [I-D.ietf-isis-ipv6] and
TLV 237 [I-D.ietf-isis-wg-multi-topology]. The Administrative Tag
Sub-TLV has following structure:
The Administrative Tag SHALL be encoded as one or more 8 octet o 1 octet of type (value: 1)
unsigned integers using Sub-TLV 2 in TLV-135 [3], TLV 235 [6], TLV
236 [7] and TLV 237 [6]. The 64-bit Administrative Tag Sub-TLV has
following structure:
1 octet of type (value: 2) o 1 octet of length (value: multiple of 4)
1 octet of length (value: multiple of 8)
one or more instances of 8 octets of administrative tag
An implementation MAY consider only one of the encoded tags, in which o one or more instances of 4 octets of administrative tag
case the first encoded tag MUST be considered. A tag value of zero
is reserved and SHOULD be treated as "no tag".
3. Ordering of Tags On receipt, an implementation MAY consider only one encoded tag, in
which case the first encoded tag MUST be considered and any
additional tags ignored. A tag value of zero is reserved and SHOULD
be treated as "no tag".
The semantics of the tag order are implementation-dependent. That 3.2. 64-bit Administrative Tag Sub-TLV 2
is, there is no implied meaning to the ordering of the tags that
indicates a certain operation or set of operations need be performed
based on the order of the tags. Each tag SHOULD be treated as an
autonomous identifier that MAY be used in policy to perform a policy
action. Whether or not tag A precedes or succeeds tag B SHOULD not
change the meaning of the tag set. However, an implementation MAY
wish to preserve tag ordering such that an ordered set of tags has
meaning to the local policy.
Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 The Administrative Tag SHALL be encoded as one or more 8 octet
and/or 237, that have associated SubTLV(s) 1 and/or 2, MAY operate on unsigned integers using Sub-TLV 2 in TLV-135 [RFC3784], TLV 235
the tag values as warranted by the implementation. If an [I-D.ietf-isis-wg-multi-topology], TLV 236 [I-D.ietf-isis-ipv6] and
implementation needs to change tag values, for example, at an area TLV 237 [I-D.ietf-isis-wg-multi-topology]. The 64-bit Administrative
boundary, then the TLV(s) SHOULD be copied to the newly generated Tag Sub-TLV has following structure:
Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s)
MAY change as dictated by the policy action. In the event that no
change is required, the SubTLV(s) SHOULD be copied in order into the
new LSP, such that ordering is preserved.
4. Compliance o 1 octet of type (value: 2)
A compliant IS-IS implementation MUST be able to assign one tag to o 1 octet of length (value: multiple of 8)
any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV
236, TLV 237.
A compliant IS-IS implementation MAY be able to assign more than one o one or more instances of 8 octets of administrative tag
tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235,
TLV 236, TLV 237.
A compliant IS-IS implementation MAY be able to rewrite or remove one On receipt, an implementation MAY consider only one encoded tag, in
or more tags associated with a prefix in any of the following TLVs: which case the first encoded tag MUST be considered and any
TLV 135, TLV 235, TLV 236, TLV 237. additional tags ignored. A tag value of zero is reserved and SHOULD
be treated as "no tag".
5. Operations 4. Ordering of Tags
An administrator associates an Administrative Tag value with some The semantics of the tag order are implementation-dependent. That
interesting property. When IS-IS advertises reachability for some IP is, there is no implied meaning to the ordering of the tags that
prefix that has that property, it adds the Administrative Tag to the indicates a certain operation or set of operations need be performed
IP reachability information TLV for that prefix, and the tag "sticks" based on the order of the tags. Each tag SHOULD be treated as an
to the prefix as it is flooded throughout the routing domain. autonomous identifier that MAY be used in policy to perform a policy
action. Whether or not tag A precedes or succeeds tag B SHOULD not
change the meaning of the tag set. However, when propagating TLVs
containing multiple tags between levels, an implementation SHOULD
preserve the ordering such that the first tag remains the first tag,
so that implementations which only recognise a single tag will have a
consistent view across levels.
Consider the network in figure 1. We wish to "leak" L1 prefixes [5] Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236
with some property, A, from L2 to the L1 router R1. Without policy- and/or 237, that have associated SubTLV(s) 1 and/or 2, MAY operate on
groups, there is no way for R2 to know property A prefixes from the tag values as warranted by the implementation. If an
property B prefixes. implementation needs to change tag values, for example, when
propagating TLVs between levels at an area boundary, then the TLV(s)
SHOULD be copied to the newly generated Level-1 or Level-2 LSP at
which point, the contents of the SubTLV(s) MAY change as dictated by
the policy action. In the event that no change is required, the
SubTLV(s) SHOULD be copied in order into the new LSP, such that
ordering is preserved.
R2--------R3--------R4 5. Compliance
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
Figure 1 A compliant IS-IS implementation MUST be able to assign one tag to
any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV
236, TLV 237. It MUST be able to interpret a single tag present in
the sub-TLV, or the first tag where there is more than one tag
present in the sub-TLV
We associate Administrative Tag 100 with property A, and have R5 A compliant IS-IS implementation MAY be able to assign more than one
attach that value to the IP extended reachability information TLV for tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235,
prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with TLV 236, TLV 237. It MAY be able to interpret the second and
Administrative Tag 100, and leak to L1." subsequent tags where more than one tag is present in the sub-TLV
The previous example is rather simplistic; it seems that it would be A compliant IS-IS implementation MAY be able to rewrite or remove one
just as easy for R2 simply to match the prefix 1.1.2.0/24. However, or more tags associated with a prefix in any of the following TLVs:
if there are a large number of routers that need to apply some policy TLV 135, TLV 235, TLV 236, TLV 237 when propagating TLVs between
according to property A and large number of "A" prefixes, this levels.
mechanism can be quite helpful.
6. Security Considerations 6. Operations
This document raises no new security issues for IS-IS, as any An administrator associates an Administrative Tag value with some
annotations to IP prefixes should not pass outside the administrative interesting property. When IS-IS advertises reachability for some IP
control of the network operator of the IS-IS domain. Such an prefix that has that property, it adds the Administrative Tag to the
allowance would violate the spirit of Interior Gateway Protocols in IP reachability information TLV for that prefix, and the tag "sticks"
general and IS-IS in particular to the prefix as it is flooded throughout the routing domain.
7. IANA Considerations Consider the network in Figure 1. We wish to "leak" L1 prefixes
[RFC2966] with some property, A, from L2 to the L1 router R1.
The authors have chosen "1" as the type code of the 32-bits Without policy- groups, there is no way for R2 to know property A
Administrative Tag Sub-TLV and "2" as the type code of the 64-bits prefixes from property B prefixes.
Administrative Tag Sub-TLV. These values must be allocated by IANA.
8. Intellectual Property Statement R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
The IETF takes no position regarding the validity or scope of any Figure 1: Example of usage
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 We associate Administrative Tag 100 with property A, and have R5
assurances of licenses to be made available, or the result of an attach that value to the IP extended reachability information TLV for
attempt made to obtain a general license or permission for the use of prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with
such proprietary rights by implementers or users of this Administrative Tag 100, and leak to L1."
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 The previous example is rather simplistic; it seems that it would be
copyrights, patents or patent applications, or other proprietary just as easy for R2 simply to match the prefix 1.1.2.0/24. However,
rights that may cover technology that may be required to implement if there are a large number of routers that need to apply some policy
this standard. Please address the information to the IETF at ietf- according to property A and large number of "A" prefixes, this
ipr@ietf.org.. mechanism can be quite helpful.
8.1. IPR Disclosure Acknowledgement Implementations which support only a single tag and those which
support multiple tags may co-exist in the same IS-IS domain. An
implementatation supporting multiple tags SHOULD therefor assign any
tag which is required to be interpretted by all systems as the first
tag in any set of multiple tags.
By submitting this Internet-Draft, I certify that any applicable 7. Security Considerations
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
9. Acknowledgments This document raises no new security issues for IS-IS, as any
annotations to IP prefixes should not pass outside the administrative
control of the network operator of the IS-IS domain. Such an
allowance would violate the spirit of Interior Gateway Protocols in
general and IS-IS in particular
The authors would like to thank Henk Smit for clarifying the best 8. IANA Considerations
place to describe this new information, Tony Li and Tony Przygienda
for useful comments on this draft, Danny McPherson for some much
needed formatting assistance, and Mike Shand for useful discussions
on encoding structure of the sub-TLV.
10. References The authors have chosen "1" as the type code of the 32-bits
Administrative Tag Sub-TLV and "2" as the type code of the 64-bits
Administrative Tag Sub-TLV. These values must be allocated by IANA.
10.1. Normative references 9. Manageability Considerations
[RFC] Bradner, S., "Key words for use in RFCs to indicate These extensions which have been designed, developed and deployed for
requirements levels", RFC 2119, March 1997. many years do not have any new impact on management and operation of
the ISIS protocol via this standardization process.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 10. Acknowledgements
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF The authors would like to thank Henk Smit for clarifying the best
Technology", BCP 79, RFC 3668, February 2004. place to describe this new information, Tony Li and Tony Przygienda
for useful comments on this draft, Danny McPherson for some much
needed formatting assistance.
[1] "Intermediate System to Intermediate System Intra-Domain Routing 11. References
Exchange Protocol " ISO 10589.
[2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 11.1. Normative References
environments", RFC 1195, December 1990.
[3] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC [ISO10589]
3784, June 2004. International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002.
[4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, dual environments", RFC 1195, December 1990.
September 1999.
[5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
with Two-Level IS-IS" RFC 2966, October 2000 Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 11.2. Informative References
[6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology [I-D.ietf-isis-ipv6]
Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April Hopps, C., "Routing IPv6 with IS-IS",
2002. draft-ietf-isis-ipv6-07 (work in progress), October 2007.
[7] Hopps, C., "Routing IPv6 with IS-IS", draft-ietf-isis-ipv6- [I-D.ietf-isis-wg-multi-topology]
05.txt, January 2003 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in
IS-IS", draft-ietf-isis-wg-multi-topology-12 (work in
progress), November 2007.
11. Editors' Address [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966,
October 2000.
Christian Martin [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
Verizon System (IS-IS) Extensions for Traffic Engineering (TE)",
1880 Campus Commons Dr RFC 3784, June 2004.
Reston, VA 20191
Email: cmartin@verizon.com
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico, 200
00142 Roma - Italy
email: sprevidi@cisco.com
Brad Neal Authors' Addresses
Broadwing Communications
1835 Kramer Lane - Suite 100
Austin, TX 78758
USA
Email: bneal@broadwing.com
Full Copyright Statement Stefano Previdi
Cisco Systems
Via Del Serafico, 200
00142 Rome,
Italy
Copyright (C) The Internet Society (2005). This document is subject to Email: sprevidi@cisco.com
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 Mike Shand (editor)
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR Cisco Systems
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 250, Longwater Avenue.
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, Reading, Berks RG2 6GB
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE UK
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Phone: +44 208 824 8690
Email: mshand@cisco.com
Christian Martin
Verizon
1880 Campus Commons Dr
Reston, VA 20191
USA
Email: cmartin@verizon.com
Brad Neal
Broadwing Communications
1835 Kramer Lane - Suite 100
Austin, TX 78758
USA
Email: bneal@broadwing.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
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 implementers 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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 75 change blocks. 
240 lines changed or deleted 244 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/