| < 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/ | ||||