< draft-ietf-isis-admin-tags-02.txt   draft-ietf-isis-admin-tags-03.txt >
Network Working Group Christian Martin
INTERNET DRAFT Verizon
Expiration Date: January 2005 Brad Neal
Broadwing Communications
Stefano Previdi
July 2004 Cisco Systems
A Policy Control Mechanism in IS-IS Using Administrative Tags IS-IS Working Group Christian Martin
<draft-ietf-isis-admin-tags-02.txt> Verizon
IETF Internet Draft Stefano Previdi
Cisco Systems
Brad Neal
Broadwing Communications
1. Status of this Memo Expires: August 2005 February 2005
This document is an Internet-Draft and is in full conformance with A Policy Control Mechanism in IS-IS Using Administrative Tags
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering <draft-ietf-isis-admin-tags-03.txt>
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 Status of this Memo
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 By submitting this Internet-Draft, I certify that any applicable
http://www.ietf.org/ietf/1id-abstracts.txt patent or 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.
The list of Internet-Draft Shadow Directories can be accessed at This document is an Internet-Draft and is in full conformance with
http://www.ietf.org/shadow.html. all provisions of Section 10 of RFC2026. 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.
2. Abstract 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."
This document describes an extension to the IS-IS protocol to add The list of current Internet-Drafts can be accessed at
operational capabilities that allow for ease of management and http://www.ietf.org/ietf/1id-abstracts.txt.
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.
3. Specification of Requirements The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Abstract
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
4. Introduction 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 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.
As defined in [2] and extended in [3], the IS-IS protocol may be used Conventions used in this document
to distribute IP prefix reachibility information throughout an IS-IS
domain. The IP prefix information is encoded as TLV type 128 and 130
in [2], with additional information carried in TLV 135 as specified
in [3] and TLV 235 as defined in [6]. In particular, the extended IP
Reachabilty 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 MultiTopology membership
information [6].
As of this writing no sub-TLVs have been defined; however, this draft The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
to carry administrative information about an IP prefix. document are to be interpreted as described in RFC-2119.
5. Sub-TLV Additions 1. Introduction
This draft proposes 2 new "Administrative Tag" sub-TLVs to be added As defined in [2] and extended in [3], the IS-IS protocol may be used
to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 to distribute IPv4 prefix reachability information throughout an IS-
bit unsigned integers that may be associated with an IP prefix. IS domain. In addition, thanks to extensions made in [6] and [7], IS-
Example uses of these tags include controlling redistribution between IS may be used to distribute IPv6 reachability information.
levels and areas, different routing protocols, or multiple instances
of IS-IS running on the same router, or carrying BGP standard or
extended communites.
The methods for which their use is employed is beyond the scope of The IPv4 prefix information is encoded as TLV type 128 and 130 in
this document and left to the implementer and/or operator. [2], with additional information carried in TLV 135 as specified in
[3] and TLV 235 as defined in [6]. In particular, the extended IP
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].
The encoding of the sub-TLV(s) is discussed in the following As of this writing no sub-TLVs have been defined; however, this draft
subsections. 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.
5.1. 32-bit Administrative Tag Sub-TLV 1 2. Sub-TLV Additions
The Administrative Tag shall be encoded as one or more 4 octet This draft proposes 2 new "Administrative Tag" sub-TLVs to be added
unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or
Administrative Tag Sub-TLV has following structure: more ordered, 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.
1 octet of type (value: 1) The methods for which their use is employed is beyond the scope of
1 octet of length (value: multiple of 4) this document and left to the implementer and/or operator.
one or more instances of 4 octets of administrative tag
An implementation may consider only one of the encoded tags, in which The encoding of the sub-TLV(s) is discussed in the following
case the first encoded tag must be considered. A tag value of zero subsections.
is reserved and should be treated as "no tag".
5.2. 64-bit Administrative Tag Sub-TLV 2 2.1. 32-bit Administrative Tag Sub-TLV 1
The Administrative Tag shall be encoded as one or more 8 octet The Administrative Tag SHALL be encoded as one or more 4 octet
unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The unsigned integers using Sub-TLV 1 in TLV-135 [3], TLV 235 [6], TLV
64-bit Administrative Tag Sub-TLV has following structure: 236 [7] and TLV 237 [6]. The Administrative Tag Sub-TLV has following
structure:
1 octet of type (value: 1) 1 octet of type (value: 1)
1 octet of length (value: multiple of 8) 1 octet of length (value: multiple of 4)
one or more instances of 8 octets of administrative tag one or more instances of 4 octets of administrative tag
An implementation may consider only one of the encoded tags, in which An implementation MAY consider only one of the encoded tags, in which
case the first encoded tag must be considered. A tag value of zero case the first encoded tag MUST be considered. A tag value of zero
is reserved and should be treated as "no tag". is reserved and SHOULD be treated as "no tag".
6. Ordering of Tags 2.2. 64-bit Administrative Tag Sub-TLV 2
The semantics of the tag order are implementation-dependent. That The Administrative Tag SHALL be encoded as one or more 8 octet
is, there is no implied meaning to the ordering of the tags that unsigned integers using Sub-TLV 2 in TLV-135 [3], TLV 235 [6], TLV
indicates a certain operation or set of operations need be performed, 236 [7] and TLV 237 [6]. The 64-bit Administrative Tag Sub-TLV has
based on the order of the tags. Each tag SHOULD be treated as an following structure:
autonomous identifier that MAY be used in policy to perform a policy
action. Whether or not tag A preceeds 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, that have 1 octet of type (value: 2)
associated SubTLV(s) 1 and/or 2, MAY operate on the tag values as 1 octet of length (value: multiple of 8)
warranted by the implementation. If an implementation needs to one or more instances of 8 octets of administrative tag
change tag values, for example, 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.
7. A compliant IS-IS implementation: An implementation MAY consider only one of the encoded tags, in which
case the first encoded tag MUST be considered. A tag value of zero
is reserved and SHOULD be treated as "no tag".
MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or 3. Ordering of Tags
235.
MAY be able to assign more than one tag to any IP prefix in TLV(s) The semantics of the tag order are implementation-dependent. That
135 and/or 235. 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.
MAY be able to rewrite or remove one or more tags associated with a Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236
prefix in TLV(s) 135 and/or 235 upon LSP generation at an area and/or 237, that have associated SubTLV(s) 1 and/or 2, MAY operate on
boundary. the tag values as warranted by the implementation. If an
implementation needs to change tag values, for example, 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.
8. Operation 4. Compliance
An administrator associates an Administrative Tag value with some A compliant IS-IS implementation MUST be able to assign one tag to
interesting property. When IS-IS advertises reachability for some IP any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV
prefix that has that property, it adds the Administrative Tag to the 236, TLV 237.
IP reachability information TLV for that prefix, and the tag "sticks"
to the prefix as it is flooded throughout the routing domian.
Consider the network in figure 1. We wish to "leak" L1 prefixes [5] A compliant IS-IS implementation MAY be able to assign more than one
with some property, A, from L2 to the L1 router R1. Without policy- tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235,
groups, there is no way for R2 to know property A prefixes from TLV 236, TLV 237.
property B prefixes.
R2--------R3--------R4 A compliant IS-IS implementation MAY be able to rewrite or remove one
L2 / \ or more tags associated with a prefix in any of the following TLVs:
- - - /- - - - - - - - - - - - - - TLV 135, TLV 235, TLV 236, TLV 237.
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
Figure 1 5. Operations
We associate Administrative Tag 100 with property A, and have R5 An administrator associates an Administrative Tag value with some
attach that value to the IP extended reachability information TLV for interesting property. When IS-IS advertises reachability for some IP
prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with prefix that has that property, it adds the Administrative Tag to the
Administrative Tag 100, and leak to L1." IP reachability information TLV for that prefix, and the tag "sticks"
to the prefix as it is flooded throughout the routing domain.
The previous example is rather simplistic; it seems that it would be Consider the network in figure 1. We wish to "leak" L1 prefixes [5]
just as easy for R2 simply to match the prefix 1.1.2.0/24. However, with some property, A, from L2 to the L1 router R1. Without policy-
if there are a large number of routers that need to apply some policy groups, there is no way for R2 to know property A prefixes from
according to property A and large number of "A" prefixes, this property B prefixes.
mechanism can be quite helpful.
9. Security Considerations R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
This document raises no new security issues for IS-IS, as any Figure 1
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.
10. IANA Considerations We associate Administrative Tag 100 with property A, and have R5
attach that value to the IP extended reachability information TLV for
prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with
Administrative Tag 100, and leak to L1."
The authors have chosen "1" as the typecode of the 32-bit The previous example is rather simplistic; it seems that it would be
Administrative Tag sub-TLV and "2" as the typecode of the 64-bt just as easy for R2 simply to match the prefix 1.1.2.0/24. However,
Administrative Tag SubTLV. These values must be allocated by IANA. if there are a large number of routers that need to apply some policy
according to property A and large number of "A" prefixes, this
mechanism can be quite helpful.
11. Acknowledgments 6. Security Considerations
The authors would like to thank Henk Smit for clarifying the best This document raises no new security issues for IS-IS, as any
place to describe this new information, Tony Li and Tony Przygienda annotations to IP prefixes should not pass outside the administrative
for useful comments on this draft, Danny McPherson for some much control of the network operator of the IS-IS domain. Such an
needed formatting assistance, and Mike Shand for useful discussions allowance would violate the spirit of Interior Gateway Protocols in
on encoding structure of the sub-TLV. general and IS-IS in particular
12. References 7. IANA Considerations
[1] "Intermediate System to Intermediate System Intra-Domain Routeing The authors have chosen "1" as the type code of the 32-bits
Exchange Protocol for use in Conjunction with the Protocol for Administrative Tag Sub-TLV and "2" as the type code of the 64-bits
Providing the Connectionless-mode Network Service (ISO 8473)", Administrative Tag Sub-TLV. These values must be allocated by IANA.
ISO 10589.
[2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and 8. Intellectual Property Statement
dual environments", RFC 1195, December 1990.
[3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", The IETF takes no position regarding the validity or scope of any
Internet Draft, "Work in Progress", September 2000. 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.
[4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, Copies of IPR disclosures made to the IETF Secretariat and any
J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, assurances of licenses to be made available, or the result of an
September 1999. 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.
[5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution The IETF invites any interested party to bring to its attention any
with Two-Level IS-IS" RFC 2966, October 2000 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..
[6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology 8.1. IPR Disclosure Acknowledgement
Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April
2002.
13. Authors' Address By submitting this Internet-Draft, I certify that any applicable
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.
Christian Martin 9. Acknowledgments
Verizon
1880 Campus Commons Dr
Reston, VA 20191
Email: cmartin@verizon.com
Brad Neal The authors would like to thank Henk Smit for clarifying the best
Broadwing Communications place to describe this new information, Tony Li and Tony Przygienda
1835 Kramer Lane - Suite 100 for useful comments on this draft, Danny McPherson for some much
Austin, TX 78758 needed formatting assistance, and Mike Shand for useful discussions
USA on encoding structure of the sub-TLV.
Email: bneal@broadwing.com
Stefano Previdi 10. References
Cisco Systems, Inc.
De Kleetlaan 6A 10.1. Normative references
1831 Diegem - Belgium
email: sprevidi@cisco.com [RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[1] "Intermediate System to Intermediate System Intra-Domain Routing
Exchange Protocol " ISO 10589.
[2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[3] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC
3784, June 2004.
[4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus,
J., "Requirements for Traffic Engineering Over MPLS," RFC 2702,
September 1999.
[5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution
with Two-Level IS-IS" RFC 2966, October 2000
10.2. Informative References
[6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology
Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April
2002.
[7] Hopps, C., "Routing IPv6 with IS-IS", draft-ietf-isis-ipv6-
05.txt, January 2003
11. Editors' Address
Christian Martin
Verizon
1880 Campus Commons Dr
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
Broadwing Communications
1835 Kramer Lane - Suite 100
Austin, TX 78758
USA
Email: bneal@broadwing.com
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.
 End of changes. 58 change blocks. 
186 lines changed or deleted 194 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/