< draft-martin-neal-policy-isis-admin-tags-04.txt   draft-martin-neal-policy-isis-admin-tags-05.txt >
Network Working Group Christian Martin Network Working Group Christian Martin
INTERNET DRAFT Verizon Internet Services INTERNET DRAFT Verizon Internet Services
Brad Neal Brad Neal
Broadwing Communications Broadwing Communications
Stefano Previdi Stefano Previdi
May 2002 Cisco Systems April 2002 Cisco Systems
A Policy Control Mechanism is IS-IS Using Administrative Tags A Policy Control Mechanism is IS-IS Using Administrative Tags
<draft-martin-neal-policy-isis-admin-tags-04.txt> <draft-martin-neal-policy-isis-admin-tags-05.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 40 skipping to change at page 1, line 41
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract 2. Abstract
This document describes an extension to the IS-IS protocol to add This document describes an extension to the IS-IS protocol to add
operational capabilities that allow for ease of management and operational capabilities that allow for ease of management and
control over IP prefix distribution within an IS-IS domain. The IS- control over IP prefix distribution within an IS-IS domain. The IS-
IS protocol is specified in [1], with extensions for supporting IPv4 IS protocol is specified in [1], with extensions for supporting IPv4
specified in [2] and further enhancements for Traffic Engineering [4] specified in [2] and further enhancements for Traffic Engineering [4]
in [3]. in [3] and [6].
This document enhances the IS-IS protocol by extending the This document enhances the IS-IS protocol by extending the
information that a Intermediate System (IS) [router] can place in information that a Intermediate System (IS) [router] can place in
Link State Protocol Data Units (LSPs) as specified in [2]. This Link State Protocol Data Units (LSPs) as specified in [2]. This
Martin, Neal, Previdi [Page 1]^L
extension will provide operators with a mechanism to control IP extension will provide operators with a mechanism to control IP
prefix distribution throughout multi-level IS-IS domains. 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 such future TLVs as it is used in the currently defined TLVs.
3. Specification of Requirements 3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
4. Introduction 4. Introduction
As defined in [2] and extended in [3], the IS-IS protocol may be used As defined in [2] and extended in [3], the IS-IS protocol may be used
to distribute IP prefix reachibility information throughout an IS-IS to distribute IP prefix reachibility information throughout an IS-IS
domain. The IP prefix information is encoded as TLV type 128 and 130 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 in [2], with additional information carried in TLV 135 as specified
[3]. In particular, the extended IP Reachabilty TLV (135) contains in [3] and TLV 235 as defined in [6]. In particular, the extended IP
support for a larger metric space, an up/down bit to indicate Reachabilty TLV (135) contains support for a larger metric space, an
redistribution between different levels in the hierarchy, an IP up/down bit to indicate redistribution between different levels in
prefix, and one or more sub-TLVs that can be used to carry specific the hierarchy, an IP prefix, and one or more sub-TLVs that can be
information about the prefix. 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 As of this writing no sub-TLVs have been defined; however, this draft
proposes a new sub-TLV that may be used to carry administrative proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used
information about an IP prefix. to carry administrative information about an IP prefix.
5. Sub-TLV Additions 5. Sub-TLV Additions
This draft proposes a new "Administrative Tag" sub-TLV to be added to This draft proposes 2 new "Administrative Tag" sub-TLVs to be added
TLV 135. This TLV specifies one or more 32 bit unsigned integers to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64
that may be associated with an IP prefix. Example uses of this tag bit unsigned integers that may be associated with an IP prefix.
include controlling redistribution between levels and areas, Example uses of these tags include controlling redistribution between
different routing protocols, or multiple instances of IS-IS running levels and areas, different routing protocols, multiple instances
on the same router. of IS-IS running on the same router, or for carrying BGP standard or
extended communites.
The methods for which their use is employed is beyond the scope of The methods for which their use is employed is beyond the scope of
this document and left to the implementer and/or operator. this document and left to the implementer and/or operator.
The encoding of the sub-TLV is discussed in the following subsection. The encoding of the sub-TLV(s) is discussed in the following
subsections.
Martin, Neal, Previdi [Page 2]^L 5.1. 32-bit Administrative Tag Sub-TLV 1
5.1. Administrative Tag Sub-TLV 1
The Administrative Tag shall be encoded as one or more 4 octet The Administrative Tag shall be encoded as one or more 4 octet
unsigned integers using Sub-TLV 1 in TLV-135 [3]. The Administrative unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The
Tag Sub-TLV has following structure: 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 4) 1 octet of length (value: multiple of 4)
one or more instances of 4 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. A compliant IS-IS implementation: 5.2. 64-bit Administrative Tag Sub-TLV 2
MUST be able to assign one tag to any IP prefix in TLV 135. The Administrative Tag shall be encoded as one or more 8 octet
unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The
64-bit Administrative Tag Sub-TLV has following structure:
MAY be able to assign more than one tag to any IP prefix in TLV 135. 1 octet of type (value: 2)
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
case the first encoded tag must be considered. A tag value of zero
is reserved and should be treated as "no tag".
6. Ordering of Tags
The semantics of the tag order are implementation-dependent. That
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 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
associated SubTLV(s) 1 and/or 2, MAY operate on 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.
7. A compliant IS-IS implementation:
MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or
235.
MAY be able to assign more than one tag to any IP prefix in TLV(s)
135 and/or 235.
MAY be able to rewrite or remove one or more tags associated with a MAY be able to rewrite or remove one or more tags associated with a
prefix in TLV 135. prefix in TLV(s) 135 and/or 235 upon LSP generation at an area
boundary.
7. Operation 8. Operation
An administrator associates an Administrative Tag value with some An administrator associates an Administrative Tag value with some
interesting property. When IS-IS advertises reachability for some IP interesting property. When IS-IS advertises reachability for some IP
prefix that has that property, it adds the Administrative Tag to the prefix that has that property, it adds the Administrative Tag to the
IP reachability information TLV for that prefix, and the tag "sticks" IP reachability information TLV for that prefix, and the tag "sticks"
to the prefix as it is flooded throughout the routing domian. to the prefix as it is flooded throughout the routing domian.
Consider the network in figure 1. We wish to "leak" L1 prefixes [5] Consider the network in figure 1. We wish to "leak" L1 prefixes [5]
with some property, A, from L2 to the L1 router R1. Without policy- with some property, A, from L2 to the L1 router R1. Without policy-
groups, there is no way for R2 to know property A prefixes from groups, there is no way for R2 to know property A prefixes from
property B prefixes. property B prefixes.
R2--------R3--------R4 R2--------R3--------R4
L2 / \ L2 / \
- - - /- - - - - - - - - - - - - - - - - /- - - - - - - - - - - \ - -
L1 / \ L1 / R1
R1 R5----1.1.1.0/24 (A) R5----1.1.1.0/24 (A) |
| |
|
1.1.2.0/24 (B) 1.1.2.0/24 (B)
Martin, Neal, Previdi [Page 3]^L
Figure 1 Figure 1
We associate Administrative Tag 100 with property A, and have R5 We associate Administrative Tag 100 with property A, and have R5
attach that value to the IP extended reachability information TLV for attach that value to the IP extended reachability information TLV for
prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with
Administrative Tag 100, and leak to L1." Administrative Tag 100, and leak to L1."
The previous example is rather simplistic; it seems that it would be The previous example is rather simplistic; it seems that it would be
just as easy for R2 simply to match the prefix 1.1.1.0/24. However, just as easy for R2 simply to match the prefix 1.1.1.0/24. However,
if there are a large number of routers that need to apply some policy 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 according to property A and large number of "A" prefixes, this
mechanism can be quite helpful. mechanism can be quite helpful.
8. Security Considerations 9. Security Considerations
This document raises no new security issues for IS-IS, as any This document raises no new security issues for IS-IS, as any
annotations to IP prefixes should not pass outside the administrative annotations to IP prefixes should not pass outside the administrative
control of the network operator of the IS-IS domain. Such an control of the network operator of the IS-IS domain. Such an
allowance would violate the spirit of Interior Gateway Protocols in allowance would violate the spirit of Interior Gateway Protocols in
general and IS-IS in particular. general and IS-IS in particular.
9. IANA Considerations 10. IANA Considerations
The authors have chosen "1" as the value of the Administrative Tag The authors have chosen "1" as the typecode of the 32-bit
sub-TLV. This must be allocated by IANA. Administrative Tag sub-TLV and "2" as the typecode of the 64-bt
Administrative Tag SubTLV. These values must be allocated by IANA.
10. Acknowledgments 11. Acknowledgments
The authors would like to thank Henk Smit for clarifying the best The authors would like to thank Henk Smit for clarifying the best
place to describe this new information, Tony Li for useful comments place to describe this new information, Tony Li and Tony Przygienda
on this draft, Danny McPherson for some much needed formatting for useful comments on this draft, Danny McPherson for some much
assistance, and Mike Shand for useful discussions on encoding needed formatting assistance, and Mike Shand for useful discussions
structure of the sub-TLV. on encoding structure of the sub-TLV.
Martin, Neal, Previdi [Page 4]^L 12. References
11. References
[1] "Intermediate System to Intermediate System Intra-Domain Routeing [1] "Intermediate System to Intermediate System Intra-Domain Routeing
Exchange Protocol for use in Conjunction with the Protocol for Exchange Protocol for use in Conjunction with the Protocol for
Providing the Connectionless-mode Network Service (ISO 8473)", Providing the Connectionless-mode Network Service (ISO 8473)",
ISO 10589. ISO 10589.
[2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering",
Internet Draft, "Work in Progress", September 2000. Internet Draft, "Work in Progress", September 2000.
[4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus,
J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, J., "Requirements for Traffic Engineering Over MPLS," RFC 2702,
September 1999. September 1999.
[5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution
Distribution with Two-Level IS-IS" RFC 2966, October 2000 with Two-Level IS-IS" RFC 2966, October 2000
12. Authors' Address [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.
13. Authors' Address
Christian Martin Christian Martin
Verizon Internet Services Verizon Internet Services
1880 Campus Commons Dr 1880 Campus Commons Dr
Reston, VA 20191 Reston, VA 20191
USA
Email: cmartin@gnilink.net Email: cmartin@gnilink.net
Voice: 1 (703) 2954394 Voice: 1 (703) 2954394
Fax: 1 (703) 2954279 Fax: 1 (703) 2954279
Brad Neal Brad Neal
Broadwing Communications Broadwing Communications
1835 Kramer Lane - Suite 100 1835 Kramer Lane - Suite 100
Austin, TX 78758 Austin, TX 78758
USA USA
Email: bneal@broadwing.com Email: bneal@broadwing.com
Voice: 1 (512) 7421310 Voice: 1 (512) 7421310
Fax: 1 (512) 7421333 Fax: 1 (512) 7421333
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem - Belgium 1831 Diegem - Belgium
email: sprevidi@cisco.com email: sprevidi@cisco.com
Martin, Neal, Previdi [Page 5]^L
 End of changes. 28 change blocks. 
51 lines changed or deleted 95 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/